[Cluster-devel] [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 at syzkaller.appspotmail.com> 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 at syzkaller.appspotmail.com
>>
>> ------------[ 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