Re: [GIT PULL] Orangefs (text only resend)

[Theodore Ts'o <tytso@mit.edu>]

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....)