On 7/21/21 4:58 PM, Andrew Morton wrote:
(cc gfs2 maintainers)
On Tue, 20 Jul 2021 19:07:25 -0700 syzbot <syzbot+0d5b462a6f07447991b3@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hello,
syzbot found the following issue on:
HEAD commit: d936eb238744 Revert "Makefile: Enable -Wimplicit-fallthrou..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1512834a300000
kernel config: https://syzkaller.appspot.com/x/.config?x=f1b998c1afc13578
dashboard link: https://syzkaller.appspot.com/bug?extid=0d5b462a6f07447991b3
userspace arch: i386
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+0d5b462a6f07447991b3@xxxxxxxxxxxxxxxxxxxxxxxxx
------------[ cut here ]------------
WARNING: CPU: 0 PID: 8696 at include/linux/backing-dev.h:283 inode_to_wb include/linux/backing-dev.h:283 [inline]
WARNING: CPU: 0 PID: 8696 at include/linux/backing-dev.h:283 account_page_dirtied mm/page-writeback.c:2435 [inline]
WARNING: CPU: 0 PID: 8696 at include/linux/backing-dev.h:283 __set_page_dirty+0xace/0x1070 mm/page-writeback.c:2483
Modules linked in:
CPU: 0 PID: 8696 Comm: syz-executor.0 Not tainted 5.14.0-rc1-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
RIP: 0010:inode_to_wb include/linux/backing-dev.h:283 [inline]
RIP: 0010:account_page_dirtied mm/page-writeback.c:2435 [inline]
RIP: 0010:__set_page_dirty+0xace/0x1070 mm/page-writeback.c:2483
Code: a8 01 00 00 be ff ff ff ff 48 8d 78 70 e8 0a bf 8c 07 31 ff 89 c3 89 c6 e8 3f af d8 ff 85 db 0f 85 ac f7 ff ff e8 f2 a7 d8 ff <0f> 0b e9 a0 f7 ff ff e8 e6 a7 d8 ff 4c 8d 75 08 48 b8 00 00 00 00
RSP: 0000:ffffc90000e578a0 EFLAGS: 00010093
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff888013d71c40 RSI: ffffffff819cdfce RDI: 0000000000000003
RBP: ffffea0001de0240 R08: 0000000000000000 R09: ffff888019819e07
R10: ffffffff819cdfc1 R11: 0000000000000000 R12: 0000000000000293
R13: ffff888078a38c90 R14: ffff888019819e00 R15: ffff888019819c58
FS: 0000000000000000(0000) GS:ffff88802ca00000(0063) knlGS:0000000009b20380
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00007fd805161390 CR3: 000000004c16a000 CR4: 0000000000150ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
mark_buffer_dirty+0x49a/0x5e0 fs/buffer.c:1108
gfs2_unpin+0x123/0xd10 fs/gfs2/lops.c:111
buf_lo_after_commit+0x140/0x210 fs/gfs2/lops.c:750
lops_after_commit fs/gfs2/lops.h:49 [inline]
gfs2_log_flush+0x162b/0x2940 fs/gfs2/log.c:1108
do_sync+0x5ab/0xcd0 fs/gfs2/quota.c:967
gfs2_quota_sync+0x2e2/0x660 fs/gfs2/quota.c:1310
gfs2_sync_fs+0x40/0xb0 fs/gfs2/super.c:711
__sync_filesystem fs/sync.c:39 [inline]
Seems that gfs2_unpin() is running mark_buffer_dirty() against a bh
which is attached to a non-upto-date page.
Hmm. That mark_buffer_dirty has been there since 2007, so this will
require some analysis.
A reproducer would be helpful, since we've never seen this before.
Bob Peterson
