Kernel mmb warning exposes ext4 xattr and FAT buffer bugs

A race in the Linux kernel's metadata-buffer tracking can corrupt association lists and hang a node when a filesystem attaches one buffer to more than one inode. A new early warning for that misuse has already surfaced real bugs in ext4 and FAT.

Aurelien DESBRIERES hit the failure while testing beamfs. The mmb path, which tracks dirty metadata buffers per inode mapping, briefly clears a buffer's owner under one mmb lock while deciding whether to keep it on a temporary list. In that window another CPU can claim the same buffer for a different inode, and both sides rewrite the association list. With list debugging on, the sync loop never empties and spins holding the lock, producing soft lockups and OOM kills with nothing naming the filesystem. The older inode dirty path avoided the overlap by taking a single lock shared by every inode on the block device; per-mmb locks do not cover a buffer that changes hands.

Jan Kara confirmed the design rule: each buffer may be tracked with at most one inode for life. Filesystems that attach shared buffers to several inodes get no guarantees. Handling those buffers on a list of their own, as beamfs later did, is the correct local fix. Kara asked for an assertion so buggy callers fail loudly at first misuse rather than at the later corruption.

DESBRIERES's WARN_ON_ONCE in the mark-dirty path does that. Once present, syzbot triggered it in production filesystems. In journal-less ext4, mbcache-deduplicated xattr blocks are dirtied through whichever inode reuses them, exactly the multi-inode shape the warning targets. Kara called that a real bug: those blocks should not use mmb tracking at all, and flushing belongs in ext4's own inode metadata sync. FAT hits involved directory blocks on images with overlapping clusters; whether that is only corrupt on-disk data or a free-and-reallocate race still needs work.

The same path can fire on a corrupted volume where two inodes claim one block. The existing cmpxchg still keeps the lists from tearing in that case; the warning now names which filesystem believed the map.