On Wed, Mar 26, 2025 at 03:25:07PM +0000, Matthew Wilcox wrote: > > We've got three reports now (two are syzkaller kiddie stuff, but one's a > real workload) of a warning in the page allocator from filesystems > doing reclaim. Essentially they're using GFP_NOFAIL from reclaim > context. This got me thinking about bs>PS and I realised that if we fix > this, then we're going to end up trying to do high order GFP_NOFAIL allocations > in the memory reclaim path, and that is really no bueno. > > https://lore.kernel.org/linux-mm/20250326105914.3803197-1-matt@xxxxxxxxxxxxxxxx/ Anything that does IO or blocking memory allocation from evict() context is a deadlock vector. They will also cause unpredictable memory allocation latency as direct reclaim can get stuck on them. The case that was brought up here is overlay dropping the last reference to an inode from dentry cache reclaim, and that inode having evict() run on it. The filesystems then make journal reservations (which can block waiting on IO), memory allocation (which can block waiting on IO and/or direct memory reclaim stalling), do IO directly from that context, etc. Memory reclaim is supposed to be a non-blocking operation, so inode reclaim really needs to avoid blocking or doing complex stuff that requires memory allocation or IO in the direct evict() path. Indeed, people spent -years- complaining that XFS did IO from evict() context from direct memory reclaim because this caused unacceptable memory allocation latency variations. It required significant architectural changes to XFS inode journalling and writeback to avoid blocking RMW IO during inode reclaim. It's also one of the driving reasons for XFS aggressively pushing *any* XFS-specific inode reclaim work that could block to background inodegc workers that run after ->destroy_inode has removed the inode from VFS visibility. As I understand it, Josef's recent inode reference counting changes will help with this, allowing the filesystem to hold a passive reference to the inode whilst it it gets pushed to a background context where the fs-specific cleanup code is allowed to block. This is probably the direction we need to head to solve this problem in a generic manner.... -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
