From mboxrd@z Thu Jan 1 00:00:00 1970 From: Theodore Ts'o Subject: Re: [GIT PULL] Orangefs (text only resend) Date: Mon, 7 Sep 2015 20:47:54 -0400 Message-ID: <20150908004754.GA690@thunk.org> References: <20150906063552.GA7224@lst.de> <20150906090838.GI22011@ZenIV.linux.org.uk> <20150906202019.GJ22011@ZenIV.linux.org.uk> <20150907063704.GK22011@ZenIV.linux.org.uk> <20150907232206.GL22011@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Mike Marshall , Christoph Hellwig , Linus Torvalds , linux-fsdevel , Andrew Morton , Stephen Rothwell , Boaz Harrosh , Greg Kroah-Hartman To: Al Viro Return-path: Received: from imap.thunk.org ([74.207.234.97]:39302 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751237AbbIHAsE (ORCPT ); Mon, 7 Sep 2015 20:48:04 -0400 Content-Disposition: inline In-Reply-To: <20150907232206.GL22011@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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....)