From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 9 Mar 2018 15:06:50 +1100 From: Dave Chinner To: Matthew Wilcox Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: Removing GFP_NOFS Message-ID: <20180309040650.GV7000@dastard> References: <20180308234618.GE29073@bombadil.infradead.org> <20180309013535.GU7000@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180309013535.GU7000@dastard> Sender: owner-linux-mm@kvack.org List-ID: On Fri, Mar 09, 2018 at 12:35:35PM +1100, Dave Chinner wrote: > On Thu, Mar 08, 2018 at 03:46:18PM -0800, Matthew Wilcox wrote: > > > > Do we have a strategy for eliminating GFP_NOFS? > > > > As I understand it, our intent is to mark the areas in individual > > filesystems that can't be reentered with memalloc_nofs_save()/restore() > > pairs. Once they're all done, then we can replace all the GFP_NOFS > > users with GFP_KERNEL. > > Won't be that easy, I think. We recently came across user-reported > allocation deadlocks in XFS where we were doing allocation with > pages held in the writeback state that lockdep has never triggered > on. > > https://www.spinics.net/lists/linux-xfs/msg16154.html > > IOWs, GFP_NOFS isn't a solid guide to where > memalloc_nofs_save/restore need to cover in the filesystems because > there's a surprising amount of code that isn't covered by existing > lockdep annotations to warning us about un-intended recursion > problems. > > I think we need to start with some documentation of all the generic > rules for where these will need to be set, then the per-filesystem > rules can be added on top of that... So thinking a bit further here: * page writeback state gets set and held: ->writepage should be under memalloc_nofs_save ->writepages should be under memalloc_nofs_save * page cache write path is often under AOP_FLAG_NOFS - should probably be under memalloc_nofs_save * metadata writeback that uses page cache and page writeback flags should probably be under memalloc_nofs_save What other generic code paths are susceptible to allocation deadlocks? Cheers, Dave. -- Dave Chinner david@fromorbit.com