From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dave Chinner <david@fromorbit.com>
Subject: Re: [GIT PULL] Orangefs (text only resend)
Date: Tue, 8 Sep 2015 12:49:28 +1000
Message-ID: <20150908024927.GQ26895@dastard>
References: <CAOg9mSTuTZk3grmoiMtC7L1WUfPzyav-RW=NXCSfWFhiSZOSFQ@mail.gmail.com>
 <CA+55aFwE-sVT0CUquKKz8=SR=fomJih51Z44NjqiuwejpNWnuw@mail.gmail.com>
 <20150906063552.GA7224@lst.de>
 <20150906090838.GI22011@ZenIV.linux.org.uk>
 <CAOg9mSQwVuEsZnawEyZ-wwZfrveSkv1hZ8CpbBX8OL9K+vbRmA@mail.gmail.com>
 <20150906202019.GJ22011@ZenIV.linux.org.uk>
 <20150907063704.GK22011@ZenIV.linux.org.uk>
 <CAOg9mSTbuo7Mtv8qqDs9Megm=sG6FnzDu=tSeZq8WLfEN4RZVg@mail.gmail.com>
 <20150907232206.GL22011@ZenIV.linux.org.uk>
 <20150908004754.GA690@thunk.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
	Mike Marshall <hubcap@omnibond.com>,
	Christoph Hellwig <hch@lst.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Boaz Harrosh <ooo@electrozaur.com>,
	Greg Kroah-Hartman <greg@kroah.com>
To: Theodore Ts'o <tytso@mit.edu>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from ipmail05.adl6.internode.on.net ([150.101.137.143]:5754 "EHLO
	ipmail05.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1751197AbbIHCtz (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Mon, 7 Sep 2015 22:49:55 -0400
Content-Disposition: inline
In-Reply-To: <20150908004754.GA690@thunk.org>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Mon, Sep 07, 2015 at 08:47:54PM -0400, Theodore Ts'o wrote:
> 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.

FWIW, lockdep will issue warnings on these potentially recursive
allocations, which can help you find them without having to first
deadlock the machine.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com