On Thu, Mar 26, 2015 at 10:53:02AM +0100, Michal Hocko wrote: > On Fri 20-03-15 14:48:20, Dave Chinner wrote: > > On Thu, Mar 19, 2015 at 01:44:41PM +0100, Michal Hocko wrote: > [...] > > > Or did I miss your point? Are you concerned about some fs overloading > > > filemap_fault and do some locking before delegating to filemap_fault? > > > > The latter: > > > > https://git.kernel.org/cgit/linux/kernel/git/dgc/linux-xfs.git/commit/?h=xfs-mmap-lock&id=de0e8c20ba3a65b0f15040aabbefdc1999876e6b > > Hmm. I am completely unfamiliar with the xfs code but my reading of > 964aa8d9e4d3..723cac484733 is that the newly introduced lock should be > OK from the reclaim recursion POV. It protects against truncate and > punch hole, right? Or are there any internal paths which I am missing > and would cause problems if we do GFP_FS with XFS_MMAPLOCK_SHARED held? It might be OK, but you're only looking at the example I gave you, not the fundamental issue it demonstrates. That is: filesystems may have *internal dependencies that are unknown to the page cache or mm subsystem*. Hence the page cache or mm allocations cannot arbitrarily ignore allocation constraints the filesystem assigns to mapping operations.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>