Re: [LSF/MM/BPF Topic] Filesystem reclaim & memory allocation BOF

[Dave Chinner <david@fromorbit.com>]

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@readmodwrite.com/

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@fromorbit.com