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@xxxxxxxxxxxxx
