Re: WARNING in __set_page_dirty

[Bob Peterson]

On 10/6/21 3:50 AM, Hao Sun wrote:
> Hello,
>
> When using Healer to fuzz the latest Linux kernel, the following crash
> was triggered.
>
> HEAD commit: 0513e464f900 Merge tag 'perf-tools-fixes-for-v5.15-2021-09-27'
> git tree: upstream
> console output:
> https://drive.google.com/file/d/1Tqtv5Qcx5LDPwnv7b2uJS2bilqpGfipG/view?usp=sharing
> kernel config: https://drive.google.com/file/d/1Jqhc4DpCVE8X7d-XBdQnrMoQzifTG5ho/view?usp=sharing
>
> If you fix this issue, please add the following tag to the commit:
> Reported-by: Hao Sun <sunhao.th@xxxxxxxxx>
>
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 19902 at ./include/linux/backing-dev.h:286
> inode_to_wb include/linux/backing-dev.h:283 [inline]
> WARNING: CPU: 0 PID: 19902 at ./include/linux/backing-dev.h:286
> account_page_dirtied mm/page-writeback.c:2452 [inline]
> WARNING: CPU: 0 PID: 19902 at ./include/linux/backing-dev.h:286
> __set_page_dirty+0x50b/0x6e0 mm/page-writeback.c:2500
> Modules linked in:
> CPU: 0 PID: 19902 Comm: syz-executor Not tainted 5.15.0-rc3+ #21
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
> RIP: 0010:inode_to_wb include/linux/backing-dev.h:283 [inline]
> RIP: 0010:account_page_dirtied mm/page-writeback.c:2452 [inline]
> RIP: 0010:__set_page_dirty+0x50b/0x6e0 mm/page-writeback.c:2500
> Code: fc ff ff e8 d7 0a f1 ff 49 8b 87 a8 01 00 00 be ff ff ff ff 48
> 8d 78 70 e8 a2 42 de 02 85 c0 0f 85 18 fc ff ff e8 b5 0a f1 ff <0f> 0b
> e9 0c fc ff ff e8 a9 0a f1 ff 48 89 ef e8 f1 ea d8 00 48 8b
> RSP: 0018:ffffc90003e7bd08 EFLAGS: 00010093
> RAX: 0000000000000000 RBX: ffffea000083a140 RCX: 0000000000000000
> RDX: ffff88810e1b8000 RSI: ffffffff814686ab RDI: ffffffff853ccbb6
> RBP: ffff88800ce0bec8 R08: 0000000000000001 R09: 0000000000000000
> R10: ffffc90003e7bbb8 R11: 0000000000000003 R12: ffff8881100ecc98
> R13: ffff8881045ac000 R14: 0000000000000293 R15: ffff88800ce0bec8
> FS:  00007f72d08c8700(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000003 CR3: 000000001a0a6000 CR4: 0000000000750ef0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
> PKRU: 55555554
> Call Trace:
>   mark_buffer_dirty+0x1d4/0x2b0 fs/buffer.c:1108
>   gfs2_unpin+0x74/0x460 fs/gfs2/lops.c:111
>   buf_lo_after_commit+0x6b/0x80 fs/gfs2/lops.c:750
>   lops_after_commit fs/gfs2/lops.h:49 [inline]
>   gfs2_log_flush+0x9ba/0x1050 fs/gfs2/log.c:1108
>   gfs2_sync_fs+0x3c/0x50 fs/gfs2/super.c:644
>   sync_fs_one_sb+0x40/0x50 fs/sync.c:81
>   iterate_supers+0xa7/0x130 fs/super.c:695
>   ksys_sync+0x60/0xc0 fs/sync.c:116
>   __do_sys_sync+0xa/0x10 fs/sync.c:125
>   do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>   do_syscall_64+0x34/0xb0 arch/x86/entry/common.c:80
>   entry_SYSCALL_64_after_hwframe+0x44/0xae
> RIP: 0033:0x200008ca
> Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 98 4a 2a e9 2c b8 b6 4c 0f 05 <bf> 00
> 00 40 00 c4 a3 7b f0 c5 01 41 e2 e9 c4 22 e9 aa bb 3c 00 00
> RSP: 002b:00007f72d08c7ba8 EFLAGS: 00000a83 ORIG_RAX: 00000000000000a2
> RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00000000200008ca
> RDX: 0000000000004c01 RSI: 0000000000000003 RDI: 0000000000400000
> RBP: 00000000000000eb R08: 0000000000000005 R09: 0000000000000006
> R10: 0000000000000007 R11: 0000000000000a83 R12: 000000000000000b
> R13: 000000000000000c R14: 000000000000000d R15: 00007ffe4f7c7800
Hi,

This is a long-standing problem we've known about for years, and there
has been a long-standing discussion about it. I've made some attempts to
fix it, but none have been satisfactory. Some people in the upstream
community insist there should be a 1:1 correspondence between inodes
and address spaces (which is the root of the problem), but there seems
to be no documentation to back that up. What we do know well is this
scenario, which does indeed make that assumption. While we ponder the
problem, it seems to cause no harm unless you have lockdep set, so it's
never been our highest priority to fix.

Regards,

Bob Peterson
GFS2 File System