Re: [syzbot] WARNING in __set_page_dirty

[Bob Peterson]

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