Kernel RFC fixes inode reclaim hang on ext2, FAT and kin

Christian Brauner has posted an RFC series aimed at stable kernels that stops several filesystems from permanently pinning unused inodes in memory.

Since Linux 7.3, ext2, ext4 without a journal, FAT, UDF and Minix set I_METADATA_WRITEBACK when they copy an inode into its buffer. Only fsync-style data-integrity paths clear the bit. The inode LRU isolator treats every state bit other than a simple reference as a reason to pull the inode off the reclaim list and wait for something else to put it back. Nothing ever does for this flag, so the inodes stay resident until an fsync or unmount.

On journal-less ext4 the problem is especially sharp: even an atime update sets the bit. Brauner reports that creating roughly 60 000 small files inside a 96 MiB memory cgroup OOMs the task after about 43 000 of them. An unprivileged user can therefore grow the inode cache without bound under memory pressure.

An earlier approach that offloaded the stuck inodes to a per-superblock workqueue was rejected as too heavy: it duplicated deferred reclaim machinery, needed another state bit, and left visible references that look like open deleted files. The RFC instead lets the shrinker reclaim these inodes like any other clean inode and has eviction write out the metadata the flag was tracking (unless the inode is being deleted). That matches what the same filesystems already do for the metadata buffers they keep in their own eviction paths.

Seven preparatory changes make the filesystems' metadata-sync helpers look the inode block up only in the buffer cache instead of reading it from disk, so reclaim does not perform pointless I/O. A related FAT fix ensures that directory entries for fallocated files are fully written before the inode disappears, closing a window where freed clusters could still be referenced after a crash.

The series is marked for backport to 7.3.