kernel BUG in end_buffer_async_write
Subsystems (2)
syzbot
syzbotHello,
syzbot found the following issue on:
HEAD commit: 51f269a6ecc7 Merge tag 'probes-fixes-6.4-rc4' of git://git.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=15ed0e7d280000 kernel config: https://syzkaller.appspot.com/x/.config?x=3da6c5d3e0a6c932 dashboard link: https://syzkaller.appspot.com/bug?extid=5c04210f7c7f897c1e7f compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1336c6b5280000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12c0a5a5280000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/8a8c8e41a6b0/disk-51f269a6.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/ffc3737b4233/vmlinux-51f269a6.xz
kernel image: https://storage.googleapis.com/syzbot-assets/d49888e5beb1/bzImage-51f269a6.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/99d35f050c12/mount_0.gz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
------------[ cut here ]------------ kernel BUG at fs/buffer.c:391! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 15 Comm: ksoftirqd/0 Not tainted 6.4.0-rc4-syzkaller-00268-g51f269a6ecc7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023 RIP: 0010:end_buffer_async_write+0x2db/0x340 fs/buffer.c:391 Code: 65 00 fe 4c 89 ff e8 d4 a3 ff ff be 08 00 00 00 48 89 c7 48 89 c3 e8 b4 31 e0 ff f0 80 4b 01 01 e9 07 fe ff ff e8 45 62 8d ff <0f> 0b e8 3e 62 8d ff 0f 0b 48 89 df e8 34 2b e0 ff e9 d9 fe ff ff RSP: 0018:ffffc90000147c98 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000100 RDX: ffff88801664bb80 RSI: ffffffff81f6e3fb RDI: 0000000000000001 RBP: ffff88806fbde570 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 R13: ffffffff81f6e120 R14: ffff88801e24ee00 R15: ffff88802a45a788 FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f42b45b0000 CR3: 000000007b04a000 CR4: 0000000000350ef0 Call Trace: <TASK> end_bio_bh_io_sync+0xde/0x130 fs/buffer.c:2730 bio_endio+0x5af/0x6c0 block/bio.c:1608 req_bio_endio block/blk-mq.c:761 [inline] blk_update_request+0x5c5/0x1620 block/blk-mq.c:906 blk_mq_end_request+0x59/0x4c0 block/blk-mq.c:1023 lo_complete_rq+0x1c6/0x280 drivers/block/loop.c:370 blk_complete_reqs+0xad/0xe0 block/blk-mq.c:1101 __do_softirq+0x1d4/0x905 kernel/softirq.c:571 run_ksoftirqd kernel/softirq.c:939 [inline] run_ksoftirqd+0x31/0x60 kernel/softirq.c:931 smpboot_thread_fn+0x659/0x9e0 kernel/smpboot.c:164 kthread+0x344/0x440 kernel/kthread.c:379 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:end_buffer_async_write+0x2db/0x340 fs/buffer.c:391 Code: 65 00 fe 4c 89 ff e8 d4 a3 ff ff be 08 00 00 00 48 89 c7 48 89 c3 e8 b4 31 e0 ff f0 80 4b 01 01 e9 07 fe ff ff e8 45 62 8d ff <0f> 0b e8 3e 62 8d ff 0f 0b 48 89 df e8 34 2b e0 ff e9 d9 fe ff ff RSP: 0018:ffffc90000147c98 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000100 RDX: ffff88801664bb80 RSI: ffffffff81f6e3fb RDI: 0000000000000001 RBP: ffff88806fbde570 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 R13: ffffffff81f6e120 R14: ffff88801e24ee00 R15: ffff88802a45a788 FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f42b45b0000 CR3: 000000007b04a000 CR4: 0000000000350ef0
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the bug is already fixed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to change bug's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the bug is a duplicate of another bug, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
Ryusuke Konishi
maintainerPATCH 1/1 nilfs2: fix potential bug in end_buffer_async_write
According to a syzbot report, end_buffer_async_write(), which handles the completion of block device writes, may detect abnormal condition of the buffer async_write flag and cause a BUG_ON failure when using nilfs2.
Nilfs2 itself does not use end_buffer_async_write(). But, the async_write flag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issue with race condition of competition between segments for dirty blocks") as a means of resolving double list insertion of dirty blocks in nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the resulting crash.
This modification is safe as long as it is used for file data and b-tree node blocks where the page caches are independent. However, it was irrelevant and redundant to also introduce async_write for segment summary and super root blocks that share buffers with the backing device. This led to the possibility that the BUG_ON check in end_buffer_async_write would fail as described above, if independent writebacks of the backing device occurred in parallel.
The use of async_write for segment summary buffers has already been removed in a previous change.
Fix this issue by removing the manipulation of the async_write flag for the remaining super root block buffer.
---
Andrew, please apply this as a bugfix.
This fixes a kernel bug issue reported by syzbot. This may conflict with the merged folio conversion series when backporting it to stable trees. I would like to send a separate request to the stable team in that case.
Thanks,
Ryusuke Konishi
fs/nilfs2/segment.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
fs/nilfs2/segment.c +5 -3
@@ -1703,7 +1703,6 @@ static void nilfs_segctor_prepare_write(struct nilfs_sc_info *sci)list_for_each_entry (bh, &segbuf->sb_payload_buffers, b_assoc_buffers) { -set_buffer_async_write (bh);if (bh == segbuf->sb_super_root) {if (bh->b_folio != bd_folio) {folio_lock (bd_folio);
@@ -1714,6 +1713,7 @@ static void nilfs_segctor_prepare_write(struct nilfs_sc_info *sci) }break ; } +set_buffer_async_write (bh);if (bh->b_folio != fs_folio) {nilfs_begin_folio_io (fs_folio); fs_folio = bh->b_folio;
@@ -1800,7 +1800,6 @@ static void nilfs_abort_logs(struct list_head *logs, int err)list_for_each_entry (bh, &segbuf->sb_payload_buffers, b_assoc_buffers) { -clear_buffer_async_write (bh);if (bh == segbuf->sb_super_root) {clear_buffer_uptodate (bh);if (bh->b_folio != bd_folio) {
@@ -1809,6 +1808,7 @@ static void nilfs_abort_logs(struct list_head *logs, int err) }break ; } +clear_buffer_async_write (bh);if (bh->b_folio != fs_folio) {nilfs_end_folio_io (fs_folio, err); fs_folio = bh->b_folio;
@@ -1896,8 +1896,9 @@ static void nilfs_segctor_complete_write(struct nilfs_sc_info *sci)BIT (BH_Delay) |BIT (BH_NILFS_Volatile) | BIT(BH_NILFS_Redirected)); -set_mask_bits (&bh->b_state, clear_bits, set_bits);if (bh == segbuf->sb_super_root) { +set_buffer_uptodate (bh); +clear_buffer_dirty (bh);if (bh->b_folio != bd_folio) {folio_end_writeback (bd_folio); bd_folio = bh->b_folio;
@@ -1905,6 +1906,7 @@ static void nilfs_segctor_complete_write(struct nilfs_sc_info *sci) update_sr = true;break ; } +set_mask_bits (&bh->b_state, clear_bits, set_bits);if (bh->b_folio != fs_folio) {nilfs_end_folio_io (fs_folio,0 ); fs_folio = bh->b_folio;
Signature · 1 line
2.34.1