Re: [syzbot ci] Re: buffer: warn when a buffer is attached to a second mmb

[Aurelien DESBRIERES <aurelien@hackers.camp>]

On Tue 27-10-26 01:46:29, syzbot ci wrote:
> and found the following issues:
> * WARNING in __ext4_handle_dirty_metadata
> * WARNING in fat_add_entries
> * WARNING in fat_alloc_new_dir
> * WARNING in fat_remove_entries

Jan, thanks for the Reviewed-by. Before the patch goes anywhere,
syzbot answers the question it left open, in two different ways.

The three fat hits are on crafted images (two of them print "Invalid
FSINFO signature" first): directories whose clusters overlap, so the
same buffer is one directory's and then another's. That is the
multiply claimed block the cmpxchg comment is about, on-disk data the
kernel does not control, and a WARN_ON there will be filed as a bug
for every new image syzbot finds. If the assertion is to stay, it
should not be a WARN on that path; a ratelimited pr_warn naming the
device would say the same thing without a splat. I can send that as
v2 if you prefer it.

The ext4 hit is different. It is the nojournal branch of
__ext4_handle_dirty_metadata(), reached from ext4_xattr_block_set() at
the "reusing; refcount now=N" point: an xattr block that mbcache
deduplicates between inodes, by design, marked dirty through the mmb
of whichever inode reuses it. That is one buffer on several inodes'
lists in turn, in ext4 without a journal, the shape the warning was
written for, and the window in mmb_sync() applies to it. I have not
reproduced it outside syzbot's repro and do not know ext4 well enough
to say what the right fix is there (mark_buffer_dirty() alone for a
block with h_refcount > 1, or a list of their own, as we did); that
one is yours to judge.

Aurelien