On Tue, Sep 08, 2015 at 12:22:06AM +0100, Al Viro wrote: > You don't want e.g. to have allocation request triggering an attempt to write > a dirty page on a shared mapping of a file from your fs while you are holding > a mutex that would block that attempt *and* waiting for a allocation to > succeed. Mike, To be more explicit --- any code in your writepage/writepages function, or code called from your writepage/writepages function has to do all of its allocations using GFP_NOFS. Otherwise, you can end up in a recursion where an attempt to writeback a page can trigger the VM system to try to writeback either the same page or another page, and then Hilarity Ensues, with either the code self-deadlocking, or in the best case, the kernel stack getting overrun. Note that in some cases, you could be calling kernel code that has no idea that it is being called a context which requires GFP_NOFS. In the past, I've had to change code in fs/buffer.c so that it would take a gfp_t argument, so that when it is called from a GFP_NOFS context, we can pass in a GFP so memory allocations won't result in a recursion back into the fs code. Similarly, if you have code which is not in the writepage/writepages code path, but which holds a lock which would block writepage()/writepages() from making forward progress, then you could be holding the lock, have the memory allocation force the page cleaner into action, which then tries calling your writepage()/writepages() function, which then runs into the lock that was being held at the time of the memory allocation, and once again, Hilarity Ensues[1]. Hope this helps, - Ted [1] http://tvtropes.org/pmwiki/pmwiki.php/Main/HilarityEnsues (Well, it may not be that hilarious if you're the poor sucker trying to debug the deadlock, but....) -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
