mmb_sync: b_mmb NULL window races mmb_mark_buffer_dirty

mmb_sync: b_mmb NULL window races mmb_mark_buffer_dirty

[Aurelien DESBRIERES]

Hi Jan,

While measuring beamfs on vfs.all (2c3ba1f1cb41, on v7.3-rc7) we hit a
list corruption in fs/buffer.c that I think is a window in mmb_sync()
rather than anything specific to our filesystem, so here it is with
the trace. beamfs was attaching buffers that several inodes share
(bitmap blocks, parity regions) to the allocating inode's
i_metadata_bhs, so the same buffer_head moved from one inode's list to
another's. We have since given those buffers a list of their own and
the problem is gone on our side; the window remains.

The window

mmb_sync() does, under mmb_A->lock:

	__remove_assoc_queue(mmb, bh);	/* list_del_init, b_mmb = NULL */
	smp_mb();
	if (buffer_dirty(bh) || buffer_locked(bh)) {
		list_add(&bh->b_assoc_buffers, &tmp);
		bh->b_mmb = mmb;

Between the NULL store and the restore, mmb_mark_buffer_dirty(bh, mmb_B)
on another CPU sees !bh->b_mmb, takes mmb_B->lock (a different lock),
its cmpxchg(&bh->b_mmb, NULL, mmb_B) succeeds, and list_move_tail()
writes bh->b_assoc_buffers while CPU A's list_add() does the same.
The second loop of mmb_sync() has the same shape (remove, then
list_add back to mmb->list when still dirty).

The old mark_buffer_dirty_inode() took the bdev mapping's
i_private_lock, shared by every inode of the device, so the two
writers could not overlap. A per-mmb lock protects a buffer that
belongs to one mmb for life; it does not protect the moment a buffer
changes hands. The comment above the cmpxchg says it is there for a
corrupted filesystem with multiply claimed blocks, and the kernel-doc
says the buffer is added "if it is not already on a list": that is
exactly the case the window lets through, so a corrupted ext2, fat,
minix or udf volume in which two inodes claim one indirect block
should be able to reach it as well, given an fsync on one inode while
the other dirties the buffer.

What it does when it hits

With CONFIG_DEBUG_LIST, __list_del_entry_valid_or_report() refuses the
del, list_del_init() does nothing, and the first loop of mmb_sync()
is `while (!list_empty(&mmb->list))` on a list whose head never
leaves: the CPU spins holding mmb->lock. We lost the node to it
(soft lockup from 48 s up, then kmemleak and the OOM killer).

  list_del corruption. next->prev should be ffffa26a6e8d4820, but was ffffa26a63804190. (next=ffffa26a432e1238)
  WARNING: /lib/list_debug.c:65 at __list_del_entry_valid_or_report+0xf6/0x110, CPU#0: dbench/16440
  CPU: 0 UID: 0 PID: 16440 Comm: dbench Not tainted 7.3.0-rc7 #1 PREEMPT(lazy)
  Call Trace:
   __remove_assoc_queue+0x20/0x80
   mmb_sync+0xba/0x300
   beamfs_write_inode+0x45/0x190
   __writeback_single_inode+0x480/0x630
   writeback_single_inode+0x11d/0x4d0
   sync_inode_metadata+0x46/0x70
   simple_fsync_noflush+0x55/0x90
   simple_fsync+0x16/0x40
   do_fsync+0x50/0xc0
   __x64_sys_fsync+0x13/0x20
  [...]
  rcu: INFO: rcu_preempt self-detected stall on CPU
  RIP: 0010:mmb_sync+0xc0/0x300
  [...]
  watchdog: BUG: soft lockup - CPU#0 stuck for 48s! [dbench:16440]
  watchdog: BUG: soft lockup - CPU#0 stuck for 413s! [dbench:16440]

xfstests generic/241 (dbench) on a 4-CPU x86_64 guest, kernel vfs.all
at 2c3ba1f1cb41 with CONFIG_DEBUG_LIST, PROVE_LOCKING and kmemleak.

A thought, not a patch

The NULL is observable only because the buffer is unlinked and then
relinked. Keeping b_mmb set while the buffer merely moves between
mmb->list and tmp (list_move() instead of __remove_assoc_queue() plus
list_add(), clearing b_mmb only when the buffer is actually dropped as
clean and unlocked) would leave mmb_mark_buffer_dirty() nothing to
race with inside mmb_sync(); the lockless check would then see either
the old mmb or none, never a transient NULL on a buffer that is about
to come back. I have not written or tested that, and you know what
else looks at b_mmb.

If a fix is wanted, we can run it against the module as it was before
our change, on the same guest: that is where the race showed, and the
same test passes 24 of 24 trials with the shared buffers on one list.

Aurelien

Re: mmb_sync: b_mmb NULL window races mmb_mark_buffer_dirty

[Jan Kara]

Hi!

On Sat 24-10-26 19:06:09, Aurelien DESBRIERES wrote:
> While measuring beamfs on vfs.all (2c3ba1f1cb41, on v7.3-rc7) we hit a
> list corruption in fs/buffer.c that I think is a window in mmb_sync()
> rather than anything specific to our filesystem, so here it is with
> the trace. beamfs was attaching buffers that several inodes share
> (bitmap blocks, parity regions) to the allocating inode's
> i_metadata_bhs, so the same buffer_head moved from one inode's list to
> another's. We have since given those buffers a list of their own and
> the problem is gone on our side; the window remains.

Well, yes, mmb code is all built on the assumption that each buffer has at
most one inode with which it can be tracked. If the filesystem tries to
attach it to more than one inode, all bets are off and we give no
guarantees what happens. I guess we should add an assertion to
mmb_mark_buffer_dirty() for that to warn about buggy filesystem code early.

So what you did - handling shared buffers separately - is the right fix for
the problem you were hitting.

								Honza

> The window
> 
> mmb_sync() does, under mmb_A->lock:
> 
> 	__remove_assoc_queue(mmb, bh);	/* list_del_init, b_mmb = NULL */
> 	smp_mb();
> 	if (buffer_dirty(bh) || buffer_locked(bh)) {
> 		list_add(&bh->b_assoc_buffers, &tmp);
> 		bh->b_mmb = mmb;
> 
> Between the NULL store and the restore, mmb_mark_buffer_dirty(bh, mmb_B)
> on another CPU sees !bh->b_mmb, takes mmb_B->lock (a different lock),
> its cmpxchg(&bh->b_mmb, NULL, mmb_B) succeeds, and list_move_tail()
> writes bh->b_assoc_buffers while CPU A's list_add() does the same.
> The second loop of mmb_sync() has the same shape (remove, then
> list_add back to mmb->list when still dirty).
> 
> The old mark_buffer_dirty_inode() took the bdev mapping's
> i_private_lock, shared by every inode of the device, so the two
> writers could not overlap. A per-mmb lock protects a buffer that
> belongs to one mmb for life; it does not protect the moment a buffer
> changes hands. The comment above the cmpxchg says it is there for a
> corrupted filesystem with multiply claimed blocks, and the kernel-doc
> says the buffer is added "if it is not already on a list": that is
> exactly the case the window lets through, so a corrupted ext2, fat,
> minix or udf volume in which two inodes claim one indirect block
> should be able to reach it as well, given an fsync on one inode while
> the other dirties the buffer.
> 
> What it does when it hits
> 
> With CONFIG_DEBUG_LIST, __list_del_entry_valid_or_report() refuses the
> del, list_del_init() does nothing, and the first loop of mmb_sync()
> is `while (!list_empty(&mmb->list))` on a list whose head never
> leaves: the CPU spins holding mmb->lock. We lost the node to it
> (soft lockup from 48 s up, then kmemleak and the OOM killer).
> 
>   list_del corruption. next->prev should be ffffa26a6e8d4820, but was ffffa26a63804190. (next=ffffa26a432e1238)
>   WARNING: /lib/list_debug.c:65 at __list_del_entry_valid_or_report+0xf6/0x110, CPU#0: dbench/16440
>   CPU: 0 UID: 0 PID: 16440 Comm: dbench Not tainted 7.3.0-rc7 #1 PREEMPT(lazy)
>   Call Trace:
>    __remove_assoc_queue+0x20/0x80
>    mmb_sync+0xba/0x300
>    beamfs_write_inode+0x45/0x190
>    __writeback_single_inode+0x480/0x630
>    writeback_single_inode+0x11d/0x4d0
>    sync_inode_metadata+0x46/0x70
>    simple_fsync_noflush+0x55/0x90
>    simple_fsync+0x16/0x40
>    do_fsync+0x50/0xc0
>    __x64_sys_fsync+0x13/0x20
>   [...]
>   rcu: INFO: rcu_preempt self-detected stall on CPU
>   RIP: 0010:mmb_sync+0xc0/0x300
>   [...]
>   watchdog: BUG: soft lockup - CPU#0 stuck for 48s! [dbench:16440]
>   watchdog: BUG: soft lockup - CPU#0 stuck for 413s! [dbench:16440]
> 
> xfstests generic/241 (dbench) on a 4-CPU x86_64 guest, kernel vfs.all
> at 2c3ba1f1cb41 with CONFIG_DEBUG_LIST, PROVE_LOCKING and kmemleak.
> 
> A thought, not a patch
> 
> The NULL is observable only because the buffer is unlinked and then
> relinked. Keeping b_mmb set while the buffer merely moves between
> mmb->list and tmp (list_move() instead of __remove_assoc_queue() plus
> list_add(), clearing b_mmb only when the buffer is actually dropped as
> clean and unlocked) would leave mmb_mark_buffer_dirty() nothing to
> race with inside mmb_sync(); the lockless check would then see either
> the old mmb or none, never a transient NULL on a buffer that is about
> to come back. I have not written or tested that, and you know what
> else looks at b_mmb.
> 
> If a fix is wanted, we can run it against the module as it was before
> our change, on the same guest: that is where the race showed, and the
> same test passes 24 of 24 trials with the shared buffers on one list.
> 
> Aurelien
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: mmb_sync: b_mmb NULL window races mmb_mark_buffer_dirty

[Aurelien DESBRIERES]

On Mon 26-10-26 14:08:12, Jan Kara wrote:
> Well, yes, mmb code is all built on the assumption that each buffer has at
> most one inode with which it can be tracked. If the filesystem tries to
> attach it to more than one inode, all bets are off and we give no
> guarantees what happens. I guess we should add an assertion to
> mmb_mark_buffer_dirty() for that to warn about buggy filesystem code early.
>
> So what you did - handling shared buffers separately - is the right fix for
> the problem you were hitting.

Thanks, that settles it: one buffer, one mmb, and our fix stands.

The assertion in mmb_mark_buffer_dirty() I can send, if you want it
from here: a WARN_ON_ONCE on bh->b_mmb set to another mmb, before the
NULL check. We still have the module that attached shared buffers to
several inodes, so the warning can be shown firing on the same
generic/241 run that corrupted the list.

Aurelien

[PATCH] buffer: warn when a buffer is attached to a second mmb

[Aurelien DESBRIERES]

mmb_mark_buffer_dirty() tracks a buffer on one mapping_metadata_bhs at
most. The per-mmb lock does not protect a buffer that changes lists,
and mmb_sync() clears b_mmb for a moment under its own lock, so a
filesystem that attaches a buffer shared by several inodes to each
inode's list in turn corrupts b_assoc_buffers eventually. With
CONFIG_DEBUG_LIST the list_del is refused and mmb_sync() spins on a
list that never empties, holding mmb->lock: seen with beamfs under
dbench (xfstests generic/241) as list_del corruption, a soft lockup and
a node lost to the OOM killer, with nothing naming the filesystem.

Warn once when a buffer already tracked by another mmb is marked dirty
through a second one, so that the misuse is named at its first
occurrence rather than at the corruption it leads to. A corrupted
volume in which two inodes claim the same block reaches this as well;
the cmpxchg below keeps the lists sound in that case, and the warning
then says which filesystem believed its block map.

Suggested-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/linux-fsdevel/q472nkbfcfdumbxm3cebfnnmueqyl6uhhnper5t6e2cxajpvtu@7prjjo7k6ia3/
Assisted-by: LLM
Signed-off-by: Aurelien DESBRIERES <aurelien@hackers.camp>
---
Tested on vfs.all with beamfs, x86_64 guest, 4 CPUs:

- the module as it was before our fix, attaching the shared bitmap
  block to each allocating inode's list in turn: the warning fires at
  boot, 8.6 s in, on the first truncate that frees blocks of a file
  another inode had allocated, long before the dbench run that used
  to corrupt the list:

    WARNING: fs/buffer.c:639 at mmb_mark_buffer_dirty+0x46/0xd0, CPU#3: S01hostname-cmd/111
     beamfs_write_bitmap_block+0x191/0x1c0
     beamfs_inline_free_blocks_from+0x64/0x390
     beamfs_inline_setattr+0x127/0x4c0
     notify_change+0x33b/0x520
     do_truncate+0xbf/0xf0
     path_openat+0x8c1/0xaa0

- the module with the shared buffers on one superblock list: no
  warning at boot or under the filesystem's own tests.

 fs/buffer.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/fs/buffer.c b/fs/buffer.c
index 1dc933ba6925..e503a7ed9c37 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -627,6 +627,16 @@ void write_boundary_block(struct block_device *bdev,
 void mmb_mark_buffer_dirty(struct buffer_head *bh,
 			   struct mapping_metadata_bhs *mmb)
 {
+	struct mapping_metadata_bhs *cur = READ_ONCE(bh->b_mmb);
+
+	/*
+	 * A buffer is tracked by one mmb at most. The per-mmb lock does
+	 * not cover a buffer that changes lists, and mmb_sync() clears
+	 * b_mmb for a moment under its own lock, so a filesystem that
+	 * attaches a buffer to a second mmb corrupts b_assoc_buffers
+	 * sooner or later. Name it here, before the lists do.
+	 */
+	WARN_ON_ONCE(cur && cur != mmb);
 	mark_buffer_dirty(bh);
 	if (!bh->b_mmb) {
 		spin_lock(&mmb->lock);

base-commit: 2c3ba1f1cb416b81d617b92a24a4bcaa48d574e3
-- 
2.55.0

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

[Jan Kara]

On Mon 26-10-26 22:36:26, Aurelien DESBRIERES wrote:
> mmb_mark_buffer_dirty() tracks a buffer on one mapping_metadata_bhs at
> most. The per-mmb lock does not protect a buffer that changes lists,
> and mmb_sync() clears b_mmb for a moment under its own lock, so a
> filesystem that attaches a buffer shared by several inodes to each
> inode's list in turn corrupts b_assoc_buffers eventually. With
> CONFIG_DEBUG_LIST the list_del is refused and mmb_sync() spins on a
> list that never empties, holding mmb->lock: seen with beamfs under
> dbench (xfstests generic/241) as list_del corruption, a soft lockup and
> a node lost to the OOM killer, with nothing naming the filesystem.
> 
> Warn once when a buffer already tracked by another mmb is marked dirty
> through a second one, so that the misuse is named at its first
> occurrence rather than at the corruption it leads to. A corrupted
> volume in which two inodes claim the same block reaches this as well;
> the cmpxchg below keeps the lists sound in that case, and the warning
> then says which filesystem believed its block map.
> 
> Suggested-by: Jan Kara <jack@suse.cz>
> Link: https://lore.kernel.org/linux-fsdevel/q472nkbfcfdumbxm3cebfnnmueqyl6uhhnper5t6e2cxajpvtu@7prjjo7k6ia3/
> Assisted-by: LLM
> Signed-off-by: Aurelien DESBRIERES <aurelien@hackers.camp>

Thanks! Looks good! Feel free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza

> ---
> Tested on vfs.all with beamfs, x86_64 guest, 4 CPUs:
> 
> - the module as it was before our fix, attaching the shared bitmap
>   block to each allocating inode's list in turn: the warning fires at
>   boot, 8.6 s in, on the first truncate that frees blocks of a file
>   another inode had allocated, long before the dbench run that used
>   to corrupt the list:
> 
>     WARNING: fs/buffer.c:639 at mmb_mark_buffer_dirty+0x46/0xd0, CPU#3: S01hostname-cmd/111
>      beamfs_write_bitmap_block+0x191/0x1c0
>      beamfs_inline_free_blocks_from+0x64/0x390
>      beamfs_inline_setattr+0x127/0x4c0
>      notify_change+0x33b/0x520
>      do_truncate+0xbf/0xf0
>      path_openat+0x8c1/0xaa0
> 
> - the module with the shared buffers on one superblock list: no
>   warning at boot or under the filesystem's own tests.
> 
>  fs/buffer.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/fs/buffer.c b/fs/buffer.c
> index 1dc933ba6925..e503a7ed9c37 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -627,6 +627,16 @@ void write_boundary_block(struct block_device *bdev,
>  void mmb_mark_buffer_dirty(struct buffer_head *bh,
>  			   struct mapping_metadata_bhs *mmb)
>  {
> +	struct mapping_metadata_bhs *cur = READ_ONCE(bh->b_mmb);
> +
> +	/*
> +	 * A buffer is tracked by one mmb at most. The per-mmb lock does
> +	 * not cover a buffer that changes lists, and mmb_sync() clears
> +	 * b_mmb for a moment under its own lock, so a filesystem that
> +	 * attaches a buffer to a second mmb corrupts b_assoc_buffers
> +	 * sooner or later. Name it here, before the lists do.
> +	 */
> +	WARN_ON_ONCE(cur && cur != mmb);
>  	mark_buffer_dirty(bh);
>  	if (!bh->b_mmb) {
>  		spin_lock(&mmb->lock);
> 
> base-commit: 2c3ba1f1cb416b81d617b92a24a4bcaa48d574e3
> -- 
> 2.55.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

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

[syzbot ci]

syzbot ci has tested the following series

[v1] buffer: warn when a buffer is attached to a second mmb
https://lore.kernel.org/all/20261026213626.301480-1-aurelien@hackers.camp
* [PATCH] buffer: warn when a buffer is attached to a second mmb

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

Full report is available here:
https://ci.syzbot.org/series/2d872051-106e-44e2-912e-9f5ffc88fe5f

***

WARNING in __ext4_handle_dirty_metadata

tree:      linux-next
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next
base:      2c3ba1f1cb416b81d617b92a24a4bcaa48d574e3
arch:      amd64
compiler:  Debian clang version 22.1.8 (1~deb13u4), Debian LLD 22.1.8
config:    https://ci.syzbot.org/builds/0103f224-dbc7-46e0-b595-6b58abedf2a1/config
syz repro: https://ci.syzbot.org/findings/e505c7df-1483-4020-9400-461d434eaf84/syz_repro

------------[ cut here ]------------
cur && cur != mmb
WARNING: fs/buffer.c:639 at mmb_mark_buffer_dirty+0x21a/0x230 fs/buffer.c:639, CPU#1: syz.2.20/5867
Modules linked in:
CPU: 1 UID: 0 PID: 5867 Comm: syz.2.20 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:mmb_mark_buffer_dirty+0x21a/0x230 fs/buffer.c:639
Code: af d7 ff 4d 89 65 00 eb 05 e8 42 c7 66 ff 4c 89 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 0c d6 8a 09 e8 27 c7 66 ff 90 <0f> 0b 90 e9 39 fe ff ff 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
RSP: 0018:ffffc900030bf238 EFLAGS: 00010293
RAX: ffffffff82615d19 RBX: ffff8881bd1af460 RCX: ffff88816f9a9e00
RDX: 0000000000000000 RSI: ffff888165b29280 RDI: ffff8881bd1af460
RBP: dffffc0000000000 R08: ffff8881bd1af467 R09: 1ffff11037a35e8c
R10: dffffc0000000000 R11: ffffed1037a35e8d R12: ffff8881bd1af4b0
R13: ffff8881bd347348 R14: ffff888165b29280 R15: 1ffff11037a35e96
FS:  00007fa2891f26c0(0000) GS:ffff8882a7cbb000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2e2cbf40e8 CR3: 000000016e66c000 CR4: 00000000000006f0
Call Trace:
 <TASK>
 __ext4_handle_dirty_metadata+0x2f5/0xa00 fs/ext4/ext4_jbd2.c:418
 ext4_xattr_block_set+0x24dd/0x29a0 fs/ext4/xattr.c:2107
 ext4_xattr_set_handle+0xed9/0x15f0 fs/ext4/xattr.c:2461
 ext4_xattr_set+0x257/0x340 fs/ext4/xattr.c:2563
 __vfs_setxattr+0x442/0x480 fs/xattr.c:223
 __vfs_setxattr_noperm+0x12a/0x660 fs/xattr.c:257
 vfs_setxattr+0x163/0x360 fs/xattr.c:344
 ovl_do_setxattr fs/overlayfs/overlayfs.h:328 [inline]
 ovl_setxattr fs/overlayfs/overlayfs.h:340 [inline]
 ovl_check_setxattr+0x15a/0x320 fs/overlayfs/util.c:898
 ovl_set_opaque_xerr fs/overlayfs/dir.c:276 [inline]
 ovl_set_opaque fs/overlayfs/dir.c:290 [inline]
 ovl_create_upper fs/overlayfs/dir.c:383 [inline]
 ovl_create_handle_whiteouts+0xb9c/0x13d0 fs/overlayfs/dir.c:643
 ovl_create_or_link+0x14d/0x270 fs/overlayfs/dir.c:685
 ovl_create_object+0x29d/0x3b0 fs/overlayfs/dir.c:722
 ovl_mkdir+0x34/0x50 fs/overlayfs/dir.c:742
 vfs_mkdir+0x40c/0x620 fs/namei.c:5420
 filename_mkdirat+0x285/0x510 fs/namei.c:5453
 __do_sys_mkdirat fs/namei.c:5474 [inline]
 __se_sys_mkdirat+0x35/0x150 fs/namei.c:5471
 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
 do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fa28839f559
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fa2891f2028 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
RAX: ffffffffffffffda RBX: 00007fa288626090 RCX: 00007fa28839f559
RDX: 00000000000001c0 RSI: 0000200000000400 RDI: ffffffffffffff9c
RBP: 00007fa288436b20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fa288626128 R14: 00007fa288626090 R15: 00007ffd68374848
 </TASK>


***

WARNING in fat_add_entries

tree:      linux-next
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next
base:      2c3ba1f1cb416b81d617b92a24a4bcaa48d574e3
arch:      amd64
compiler:  Debian clang version 22.1.8 (1~deb13u4), Debian LLD 22.1.8
config:    https://ci.syzbot.org/builds/0103f224-dbc7-46e0-b595-6b58abedf2a1/config
syz repro: https://ci.syzbot.org/findings/39f0a1b2-b9af-4d73-a1fc-ce1cd04779b5/syz_repro

FAT-fs (loop2): Invalid FSINFO signature: 0x41615252, 0x80417272 (sector = 1)
------------[ cut here ]------------
cur && cur != mmb
WARNING: fs/buffer.c:639 at mmb_mark_buffer_dirty+0x21a/0x230 fs/buffer.c:639, CPU#0: syz.2.19/5813
Modules linked in:
CPU: 0 UID: 0 PID: 5813 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:mmb_mark_buffer_dirty+0x21a/0x230 fs/buffer.c:639
Code: af d7 ff 4d 89 65 00 eb 05 e8 42 c7 66 ff 4c 89 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 0c d6 8a 09 e8 27 c7 66 ff 90 <0f> 0b 90 e9 39 fe ff ff 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
RSP: 0018:ffffc9000404f660 EFLAGS: 00010293
RAX: ffffffff82615d19 RBX: ffff88811c3c0a80 RCX: ffff888113c71e00
RDX: 0000000000000000 RSI: ffff88811bd3b3b8 RDI: ffff88811c3c0a80
RBP: dffffc0000000000 R08: ffffffff0000ffff R09: ffffffffffffffff
R10: 0000fc000f003000 R11: 65006c0069006641 R12: ffff88811c3c0ad0
R13: dffffc0000000000 R14: ffff88811bd3b3b8 R15: 1ffff1102387815a
FS:  00007f0b764146c0(0000) GS:ffff88818c4bb000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000010ebc0000 CR4: 00000000000006f0
Call Trace:
 <TASK>
 fat_add_entries+0xc9a/0x2320 fs/fat/dir.c:1410
 vfat_add_entry+0x2dd3/0x3570 fs/fat/namei_vfat.c:675
 vfat_mkdir+0x16c/0x300 fs/fat/namei_vfat.c:866
 vfs_mkdir+0x40c/0x620 fs/namei.c:5420
 filename_mkdirat+0x285/0x510 fs/namei.c:5453
 __do_sys_mkdirat fs/namei.c:5474 [inline]
 __se_sys_mkdirat+0x35/0x150 fs/namei.c:5471
 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
 do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f0b7559e3c7
Code: 00 66 90 48 89 f2 b9 00 01 00 00 48 89 fe bf 9c ff ff ff e9 db f7 ff ff 66 2e 0f 1f 84 00 00 00 00 00 90 b8 02 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f0b76413e58 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
RAX: ffffffffffffffda RBX: 00007f0b76413ee0 RCX: 00007f0b7559e3c7
RDX: 00000000000001ff RSI: 00002000000000c0 RDI: 00000000ffffff9c
RBP: 0000000000000000 R08: 0000200000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00002000000000c0
R13: 00007f0b76413ea0 R14: 0000000000000000 R15: 0000000000000000
 </TASK>


***

WARNING in fat_alloc_new_dir

tree:      linux-next
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next
base:      2c3ba1f1cb416b81d617b92a24a4bcaa48d574e3
arch:      amd64
compiler:  Debian clang version 22.1.8 (1~deb13u4), Debian LLD 22.1.8
config:    https://ci.syzbot.org/builds/0103f224-dbc7-46e0-b595-6b58abedf2a1/config
syz repro: https://ci.syzbot.org/findings/ac218fc3-8274-46ed-ad15-c9645108042b/syz_repro

FAT-fs (loop2): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
FAT-fs (loop2): Invalid FSINFO signature: 0x41615252, 0x80417272 (sector = 1)
------------[ cut here ]------------
cur && cur != mmb
WARNING: fs/buffer.c:639 at mmb_mark_buffer_dirty+0x21a/0x230 fs/buffer.c:639, CPU#0: syz.2.19/5804
Modules linked in:
CPU: 0 UID: 0 PID: 5804 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:mmb_mark_buffer_dirty+0x21a/0x230 fs/buffer.c:639
Code: af d7 ff 4d 89 65 00 eb 05 e8 42 c7 66 ff 4c 89 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 0c d6 8a 09 e8 27 c7 66 ff 90 <0f> 0b 90 e9 39 fe ff ff 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
RSP: 0018:ffffc900037bfac0 EFLAGS: 00010293
RAX: ffffffff82615d19 RBX: ffff888022008000 RCX: ffff888113ad3c00
RDX: 0000000000000000 RSI: ffff8880222733b8 RDI: ffff888022008000
RBP: dffffc0000000000 R08: ffff888022008007 R09: 1ffff11004401000
R10: dffffc0000000000 R11: ffffed1004401001 R12: ffff888022008050
R13: f8f8f8f8f1f1f1f1 R14: ffff8880222733b8 R15: 1ffff1100440100a
FS:  00007fde7c2926c0(0000) GS:ffff88818c4bb000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000022c3e000 CR4: 00000000000006f0
Call Trace:
 <TASK>
 fat_alloc_new_dir+0x7c5/0xb90 fs/fat/dir.c:1223
 vfat_mkdir+0x13a/0x300 fs/fat/namei_vfat.c:861
 vfs_mkdir+0x40c/0x620 fs/namei.c:5420
 filename_mkdirat+0x285/0x510 fs/namei.c:5453
 __do_sys_mkdirat fs/namei.c:5474 [inline]
 __se_sys_mkdirat+0x35/0x150 fs/namei.c:5471
 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
 do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fde7b39f559
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fde7c292028 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
RAX: ffffffffffffffda RBX: 00007fde7b625fa0 RCX: 00007fde7b39f559
RDX: 0000000000000040 RSI: 0000200000000100 RDI: ffffffffffffff9c
RBP: 00007fde7b436b20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fde7b626038 R14: 00007fde7b625fa0 R15: 00007ffee0058de8
 </TASK>


***

WARNING in fat_remove_entries

tree:      linux-next
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next
base:      2c3ba1f1cb416b81d617b92a24a4bcaa48d574e3
arch:      amd64
compiler:  Debian clang version 22.1.8 (1~deb13u4), Debian LLD 22.1.8
config:    https://ci.syzbot.org/builds/0103f224-dbc7-46e0-b595-6b58abedf2a1/config
syz repro: https://ci.syzbot.org/findings/09b74141-73df-447f-b681-310eb6bbab31/syz_repro

------------[ cut here ]------------
cur && cur != mmb
WARNING: fs/buffer.c:639 at mmb_mark_buffer_dirty+0x21a/0x230 fs/buffer.c:639, CPU#0: syz-executor/5735
Modules linked in:
CPU: 0 UID: 0 PID: 5735 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:mmb_mark_buffer_dirty+0x21a/0x230 fs/buffer.c:639
Code: af d7 ff 4d 89 65 00 eb 05 e8 42 c7 66 ff 4c 89 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 0c d6 8a 09 e8 27 c7 66 ff 90 <0f> 0b 90 e9 39 fe ff ff 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
RSP: 0018:ffffc9000385fb98 EFLAGS: 00010293
RAX: ffffffff82615d19 RBX: ffff8881130f0ee0 RCX: ffff888177e8bc00
RDX: 0000000000000000 RSI: ffff8881188ead68 RDI: ffff8881130f0ee0
RBP: dffffc0000000000 R08: ffffffff917a837f R09: 1ffffffff22f506f
R10: dffffc0000000000 R11: fffffbfff22f5070 R12: ffff8881130f0f30
R13: ffff8881188ead01 R14: ffff8881188ead68 R15: 1ffff1102261e1e6
FS:  0000555564cc8500(0000) GS:ffff88818c4bb000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fff31a07d40 CR3: 00000001768a8000 CR4: 00000000000006f0
Call Trace:
 <TASK>
 fat_remove_entries+0x196/0x470 fs/fat/dir.c:1090
 vfat_unlink+0x283/0x330 fs/fat/namei_vfat.c:836
 vfs_unlink+0x27b/0x6d0 fs/namei.c:5659
 filename_unlinkat+0x3cd/0x610 fs/namei.c:5729
 __do_sys_unlink fs/namei.c:5764 [inline]
 __se_sys_unlink+0x2e/0x140 fs/namei.c:5761
 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
 do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fb725d9e647
Code: 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 57 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 01 c3 48 c7 c2 e8 ff ff ff f7 d8 64 89 02 b8
RSP: 002b:00007fff31a08398 EFLAGS: 00000206 ORIG_RAX: 0000000000000057
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb725d9e647
RDX: 00007fff31a083c0 RSI: 00007fff31a08450 RDI: 00007fff31a08450
RBP: 00007fff31a08450 R08: 00007fff31a09450 R09: 00000000ffffffff
R10: 0000000000000100 R11: 0000000000000206 R12: 00007fff31a09540
R13: 00007fb725e35f63 R14: 00000000000114de R15: 00007fff31a0b700
 </TASK>


***

If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
  Tested-by: syzbot@syzkaller.appspotmail.com

---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.

To test a fix for this bug, please reply with `#syz test`
(on a separate line) and attach the patch to the email.

Notes:
- The patch will be applied on top of the tested series (as an
  incremental fix).
- To test a new version of the whole series, please send it directly
  to syzbot@lists.linux.dev.
- Arguments like custom git repos and branches are not supported.

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

[Aurelien DESBRIERES]

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

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

[Jan Kara]

On Tue 27-10-26 01:46:29, syzbot ci wrote:
> syzbot ci has tested the following series
> 
> [v1] buffer: warn when a buffer is attached to a second mmb
> https://lore.kernel.org/all/20261026213626.301480-1-aurelien@hackers.camp
> * [PATCH] buffer: warn when a buffer is attached to a second mmb
> 
> 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

Woohoo, great that we have added this. So now we have some filesystem bugs
to analyze ;). At least in ext4 case this is a real bug as xattr blocks can
be indeed shared among inodes. The right fix there is to just not track
xattr blocks with mmb and instead handle the flushing in
ext4_sync_inode_metadata().

I'm not sure about the FAT cases because directory blocks where this
triggers should better belong to a single directory. So it could be some
race with freeing & reallocating blocks. Needs more digging.

								Honza

> 
> Full report is available here:
> https://ci.syzbot.org/series/2d872051-106e-44e2-912e-9f5ffc88fe5f
> 
> ***
> 
> WARNING in __ext4_handle_dirty_metadata
> 
> tree:      linux-next
> URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next
> base:      2c3ba1f1cb416b81d617b92a24a4bcaa48d574e3
> arch:      amd64
> compiler:  Debian clang version 22.1.8 (1~deb13u4), Debian LLD 22.1.8
> config:    https://ci.syzbot.org/builds/0103f224-dbc7-46e0-b595-6b58abedf2a1/config
> syz repro: https://ci.syzbot.org/findings/e505c7df-1483-4020-9400-461d434eaf84/syz_repro
> 
> ------------[ cut here ]------------
> cur && cur != mmb
> WARNING: fs/buffer.c:639 at mmb_mark_buffer_dirty+0x21a/0x230 fs/buffer.c:639, CPU#1: syz.2.20/5867
> Modules linked in:
> CPU: 1 UID: 0 PID: 5867 Comm: syz.2.20 Not tainted syzkaller #0 PREEMPT(full) 
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
> RIP: 0010:mmb_mark_buffer_dirty+0x21a/0x230 fs/buffer.c:639
> Code: af d7 ff 4d 89 65 00 eb 05 e8 42 c7 66 ff 4c 89 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 0c d6 8a 09 e8 27 c7 66 ff 90 <0f> 0b 90 e9 39 fe ff ff 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
> RSP: 0018:ffffc900030bf238 EFLAGS: 00010293
> RAX: ffffffff82615d19 RBX: ffff8881bd1af460 RCX: ffff88816f9a9e00
> RDX: 0000000000000000 RSI: ffff888165b29280 RDI: ffff8881bd1af460
> RBP: dffffc0000000000 R08: ffff8881bd1af467 R09: 1ffff11037a35e8c
> R10: dffffc0000000000 R11: ffffed1037a35e8d R12: ffff8881bd1af4b0
> R13: ffff8881bd347348 R14: ffff888165b29280 R15: 1ffff11037a35e96
> FS:  00007fa2891f26c0(0000) GS:ffff8882a7cbb000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f2e2cbf40e8 CR3: 000000016e66c000 CR4: 00000000000006f0
> Call Trace:
>  <TASK>
>  __ext4_handle_dirty_metadata+0x2f5/0xa00 fs/ext4/ext4_jbd2.c:418
>  ext4_xattr_block_set+0x24dd/0x29a0 fs/ext4/xattr.c:2107
>  ext4_xattr_set_handle+0xed9/0x15f0 fs/ext4/xattr.c:2461
>  ext4_xattr_set+0x257/0x340 fs/ext4/xattr.c:2563
>  __vfs_setxattr+0x442/0x480 fs/xattr.c:223
>  __vfs_setxattr_noperm+0x12a/0x660 fs/xattr.c:257
>  vfs_setxattr+0x163/0x360 fs/xattr.c:344
>  ovl_do_setxattr fs/overlayfs/overlayfs.h:328 [inline]
>  ovl_setxattr fs/overlayfs/overlayfs.h:340 [inline]
>  ovl_check_setxattr+0x15a/0x320 fs/overlayfs/util.c:898
>  ovl_set_opaque_xerr fs/overlayfs/dir.c:276 [inline]
>  ovl_set_opaque fs/overlayfs/dir.c:290 [inline]
>  ovl_create_upper fs/overlayfs/dir.c:383 [inline]
>  ovl_create_handle_whiteouts+0xb9c/0x13d0 fs/overlayfs/dir.c:643
>  ovl_create_or_link+0x14d/0x270 fs/overlayfs/dir.c:685
>  ovl_create_object+0x29d/0x3b0 fs/overlayfs/dir.c:722
>  ovl_mkdir+0x34/0x50 fs/overlayfs/dir.c:742
>  vfs_mkdir+0x40c/0x620 fs/namei.c:5420
>  filename_mkdirat+0x285/0x510 fs/namei.c:5453
>  __do_sys_mkdirat fs/namei.c:5474 [inline]
>  __se_sys_mkdirat+0x35/0x150 fs/namei.c:5471
>  do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
>  do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7fa28839f559
> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007fa2891f2028 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
> RAX: ffffffffffffffda RBX: 00007fa288626090 RCX: 00007fa28839f559
> RDX: 00000000000001c0 RSI: 0000200000000400 RDI: ffffffffffffff9c
> RBP: 00007fa288436b20 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007fa288626128 R14: 00007fa288626090 R15: 00007ffd68374848
>  </TASK>
> 
> 
> ***
> 
> WARNING in fat_add_entries
> 
> tree:      linux-next
> URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next
> base:      2c3ba1f1cb416b81d617b92a24a4bcaa48d574e3
> arch:      amd64
> compiler:  Debian clang version 22.1.8 (1~deb13u4), Debian LLD 22.1.8
> config:    https://ci.syzbot.org/builds/0103f224-dbc7-46e0-b595-6b58abedf2a1/config
> syz repro: https://ci.syzbot.org/findings/39f0a1b2-b9af-4d73-a1fc-ce1cd04779b5/syz_repro
> 
> FAT-fs (loop2): Invalid FSINFO signature: 0x41615252, 0x80417272 (sector = 1)
> ------------[ cut here ]------------
> cur && cur != mmb
> WARNING: fs/buffer.c:639 at mmb_mark_buffer_dirty+0x21a/0x230 fs/buffer.c:639, CPU#0: syz.2.19/5813
> Modules linked in:
> CPU: 0 UID: 0 PID: 5813 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full) 
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
> RIP: 0010:mmb_mark_buffer_dirty+0x21a/0x230 fs/buffer.c:639
> Code: af d7 ff 4d 89 65 00 eb 05 e8 42 c7 66 ff 4c 89 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 0c d6 8a 09 e8 27 c7 66 ff 90 <0f> 0b 90 e9 39 fe ff ff 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
> RSP: 0018:ffffc9000404f660 EFLAGS: 00010293
> RAX: ffffffff82615d19 RBX: ffff88811c3c0a80 RCX: ffff888113c71e00
> RDX: 0000000000000000 RSI: ffff88811bd3b3b8 RDI: ffff88811c3c0a80
> RBP: dffffc0000000000 R08: ffffffff0000ffff R09: ffffffffffffffff
> R10: 0000fc000f003000 R11: 65006c0069006641 R12: ffff88811c3c0ad0
> R13: dffffc0000000000 R14: ffff88811bd3b3b8 R15: 1ffff1102387815a
> FS:  00007f0b764146c0(0000) GS:ffff88818c4bb000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000000 CR3: 000000010ebc0000 CR4: 00000000000006f0
> Call Trace:
>  <TASK>
>  fat_add_entries+0xc9a/0x2320 fs/fat/dir.c:1410
>  vfat_add_entry+0x2dd3/0x3570 fs/fat/namei_vfat.c:675
>  vfat_mkdir+0x16c/0x300 fs/fat/namei_vfat.c:866
>  vfs_mkdir+0x40c/0x620 fs/namei.c:5420
>  filename_mkdirat+0x285/0x510 fs/namei.c:5453
>  __do_sys_mkdirat fs/namei.c:5474 [inline]
>  __se_sys_mkdirat+0x35/0x150 fs/namei.c:5471
>  do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
>  do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f0b7559e3c7
> Code: 00 66 90 48 89 f2 b9 00 01 00 00 48 89 fe bf 9c ff ff ff e9 db f7 ff ff 66 2e 0f 1f 84 00 00 00 00 00 90 b8 02 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f0b76413e58 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
> RAX: ffffffffffffffda RBX: 00007f0b76413ee0 RCX: 00007f0b7559e3c7
> RDX: 00000000000001ff RSI: 00002000000000c0 RDI: 00000000ffffff9c
> RBP: 0000000000000000 R08: 0000200000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00002000000000c0
> R13: 00007f0b76413ea0 R14: 0000000000000000 R15: 0000000000000000
>  </TASK>
> 
> 
> ***
> 
> WARNING in fat_alloc_new_dir
> 
> tree:      linux-next
> URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next
> base:      2c3ba1f1cb416b81d617b92a24a4bcaa48d574e3
> arch:      amd64
> compiler:  Debian clang version 22.1.8 (1~deb13u4), Debian LLD 22.1.8
> config:    https://ci.syzbot.org/builds/0103f224-dbc7-46e0-b595-6b58abedf2a1/config
> syz repro: https://ci.syzbot.org/findings/ac218fc3-8274-46ed-ad15-c9645108042b/syz_repro
> 
> FAT-fs (loop2): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
> FAT-fs (loop2): Invalid FSINFO signature: 0x41615252, 0x80417272 (sector = 1)
> ------------[ cut here ]------------
> cur && cur != mmb
> WARNING: fs/buffer.c:639 at mmb_mark_buffer_dirty+0x21a/0x230 fs/buffer.c:639, CPU#0: syz.2.19/5804
> Modules linked in:
> CPU: 0 UID: 0 PID: 5804 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full) 
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
> RIP: 0010:mmb_mark_buffer_dirty+0x21a/0x230 fs/buffer.c:639
> Code: af d7 ff 4d 89 65 00 eb 05 e8 42 c7 66 ff 4c 89 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 0c d6 8a 09 e8 27 c7 66 ff 90 <0f> 0b 90 e9 39 fe ff ff 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
> RSP: 0018:ffffc900037bfac0 EFLAGS: 00010293
> RAX: ffffffff82615d19 RBX: ffff888022008000 RCX: ffff888113ad3c00
> RDX: 0000000000000000 RSI: ffff8880222733b8 RDI: ffff888022008000
> RBP: dffffc0000000000 R08: ffff888022008007 R09: 1ffff11004401000
> R10: dffffc0000000000 R11: ffffed1004401001 R12: ffff888022008050
> R13: f8f8f8f8f1f1f1f1 R14: ffff8880222733b8 R15: 1ffff1100440100a
> FS:  00007fde7c2926c0(0000) GS:ffff88818c4bb000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000000 CR3: 0000000022c3e000 CR4: 00000000000006f0
> Call Trace:
>  <TASK>
>  fat_alloc_new_dir+0x7c5/0xb90 fs/fat/dir.c:1223
>  vfat_mkdir+0x13a/0x300 fs/fat/namei_vfat.c:861
>  vfs_mkdir+0x40c/0x620 fs/namei.c:5420
>  filename_mkdirat+0x285/0x510 fs/namei.c:5453
>  __do_sys_mkdirat fs/namei.c:5474 [inline]
>  __se_sys_mkdirat+0x35/0x150 fs/namei.c:5471
>  do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
>  do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7fde7b39f559
> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007fde7c292028 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
> RAX: ffffffffffffffda RBX: 00007fde7b625fa0 RCX: 00007fde7b39f559
> RDX: 0000000000000040 RSI: 0000200000000100 RDI: ffffffffffffff9c
> RBP: 00007fde7b436b20 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007fde7b626038 R14: 00007fde7b625fa0 R15: 00007ffee0058de8
>  </TASK>
> 
> 
> ***
> 
> WARNING in fat_remove_entries
> 
> tree:      linux-next
> URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next
> base:      2c3ba1f1cb416b81d617b92a24a4bcaa48d574e3
> arch:      amd64
> compiler:  Debian clang version 22.1.8 (1~deb13u4), Debian LLD 22.1.8
> config:    https://ci.syzbot.org/builds/0103f224-dbc7-46e0-b595-6b58abedf2a1/config
> syz repro: https://ci.syzbot.org/findings/09b74141-73df-447f-b681-310eb6bbab31/syz_repro
> 
> ------------[ cut here ]------------
> cur && cur != mmb
> WARNING: fs/buffer.c:639 at mmb_mark_buffer_dirty+0x21a/0x230 fs/buffer.c:639, CPU#0: syz-executor/5735
> Modules linked in:
> CPU: 0 UID: 0 PID: 5735 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) 
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
> RIP: 0010:mmb_mark_buffer_dirty+0x21a/0x230 fs/buffer.c:639
> Code: af d7 ff 4d 89 65 00 eb 05 e8 42 c7 66 ff 4c 89 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 0c d6 8a 09 e8 27 c7 66 ff 90 <0f> 0b 90 e9 39 fe ff ff 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
> RSP: 0018:ffffc9000385fb98 EFLAGS: 00010293
> RAX: ffffffff82615d19 RBX: ffff8881130f0ee0 RCX: ffff888177e8bc00
> RDX: 0000000000000000 RSI: ffff8881188ead68 RDI: ffff8881130f0ee0
> RBP: dffffc0000000000 R08: ffffffff917a837f R09: 1ffffffff22f506f
> R10: dffffc0000000000 R11: fffffbfff22f5070 R12: ffff8881130f0f30
> R13: ffff8881188ead01 R14: ffff8881188ead68 R15: 1ffff1102261e1e6
> FS:  0000555564cc8500(0000) GS:ffff88818c4bb000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fff31a07d40 CR3: 00000001768a8000 CR4: 00000000000006f0
> Call Trace:
>  <TASK>
>  fat_remove_entries+0x196/0x470 fs/fat/dir.c:1090
>  vfat_unlink+0x283/0x330 fs/fat/namei_vfat.c:836
>  vfs_unlink+0x27b/0x6d0 fs/namei.c:5659
>  filename_unlinkat+0x3cd/0x610 fs/namei.c:5729
>  __do_sys_unlink fs/namei.c:5764 [inline]
>  __se_sys_unlink+0x2e/0x140 fs/namei.c:5761
>  do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
>  do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7fb725d9e647
> Code: 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 57 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 01 c3 48 c7 c2 e8 ff ff ff f7 d8 64 89 02 b8
> RSP: 002b:00007fff31a08398 EFLAGS: 00000206 ORIG_RAX: 0000000000000057
> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb725d9e647
> RDX: 00007fff31a083c0 RSI: 00007fff31a08450 RDI: 00007fff31a08450
> RBP: 00007fff31a08450 R08: 00007fff31a09450 R09: 00000000ffffffff
> R10: 0000000000000100 R11: 0000000000000206 R12: 00007fff31a09540
> R13: 00007fb725e35f63 R14: 00000000000114de R15: 00007fff31a0b700
>  </TASK>
> 
> 
> ***
> 
> If these findings have caused you to resend the series or submit a
> separate fix, please add the following tag to your commit message:
>   Tested-by: syzbot@syzkaller.appspotmail.com
> 
> ---
> This report is generated by a bot. It may contain errors.
> syzbot ci engineers can be reached at syzkaller@googlegroups.com.
> 
> To test a fix for this bug, please reply with `#syz test`
> (on a separate line) and attach the patch to the email.
> 
> Notes:
> - The patch will be applied on top of the tested series (as an
>   incremental fix).
> - To test a new version of the whole series, please send it directly
>   to syzbot@lists.linux.dev.
> - Arguments like custom git repos and branches are not supported.
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

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

[Aurelien DESBRIERES]

On Tue 27-10-26 13:10:55, Jan Kara wrote:
> Woohoo, great that we have added this. So now we have some filesystem bugs
> to analyze ;). At least in ext4 case this is a real bug as xattr blocks can
> be indeed shared among inodes.
[...]
> I'm not sure about the FAT cases because directory blocks where this
> triggers should better belong to a single directory. So it could be some
> race with freeing & reallocating blocks. Needs more digging.

Our mails crossed; forget the pr_warn alternative then, the WARN stays
as sent. If digging into the FAT cases from the syzbot repros helps, I
can take that on; say so and I will report what I find. Your free and
reallocate theory also describes something beamfs could do with its
indirect blocks, so I am running xfstests against the warning on our
side first.

Aurelien