WARNING in ext4_set_page_dirty

[syzbot]

Hello,

syzbot hit the following crash on upstream commit
10b84daddbec72c6b440216a69de9a9605127f7a (Sat Mar 31 17:59:00 2018 +0000)
Merge branch 'perf-urgent-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=9a44753ac327c557796a

So far this crash happened 3 times on upstream.
Unfortunately, I don't have any reproducer for this crash yet.
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=5118663967375360
Kernel config:
https://syzkaller.appspot.com/x/.config?id=-2760467897697295172
compiler: gcc (GCC) 7.1.1 20170620

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+9a4475...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.

WARNING: CPU: 0 PID: 7377 at fs/ext4/inode.c:3895
ext4_set_page_dirty+0x242/0x2b0 fs/ext4/inode.c:3895
Kernel panic - not syncing: panic_on_warn set ...

CPU: 0 PID: 7377 Comm: syz-executor1 Not tainted 4.16.0-rc7+ #9
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x24d lib/dump_stack.c:53
panic+0x1e4/0x41c kernel/panic.c:183
__warn+0x1dc/0x200 kernel/panic.c:547
report_bug+0x1f4/0x2b0 lib/bug.c:186
fixup_bug.part.10+0x37/0x80 arch/x86/kernel/traps.c:178
fixup_bug arch/x86/kernel/traps.c:247 [inline]
do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:986
RIP: 0010:ext4_set_page_dirty+0x242/0x2b0 fs/ext4/inode.c:3895
RSP: 0000:ffff88018b725df0 EFLAGS: 00010216
RAX: 0000000000040000 RBX: ffffea0006713040 RCX: ffffffff81ee1072
RDX: 0000000000002ee2 RSI: ffffc900074f3000 RDI: ffffea0006713040
RBP: ffff88018b725ec0 R08: 1ffff100316e4c1c R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 1ffff100316e4bbf
R13: ffffea0006713040 R14: ffff88018b725e98 R15: ffffea0006713060
set_page_dirty+0x2c5/0x5d0 mm/page-writeback.c:2565
set_page_dirty_lock+0xf2/0x160 mm/page-writeback.c:2590
dio_bio_complete+0x514/0x750 fs/direct-io.c:560
dio_await_completion fs/direct-io.c:581 [inline]
do_blockdev_direct_IO+0x7270/0xc960 fs/direct-io.c:1392
__blockdev_direct_IO+0x9d/0xd0 fs/direct-io.c:1421
ext4_direct_IO_read fs/ext4/inode.c:3830 [inline]
ext4_direct_IO+0xfe5/0x1980 fs/ext4/inode.c:3866
generic_file_read_iter+0x4cc/0x28e0 mm/filemap.c:2343
ext4_file_read_iter+0x113/0x160 fs/ext4/file.c:77
call_read_iter include/linux/fs.h:1776 [inline]
new_sync_read fs/read_write.c:401 [inline]
__vfs_read+0x6a7/0xa00 fs/read_write.c:413
vfs_read+0x11e/0x350 fs/read_write.c:447
SYSC_pread64 fs/read_write.c:611 [inline]
SyS_pread64+0x15b/0x190 fs/read_write.c:598
do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x454e79
RSP: 002b:00007feb4557bc68 EFLAGS: 00000246 ORIG_RAX: 0000000000000011
RAX: ffffffffffffffda RBX: 00007feb4557c6d4 RCX: 0000000000454e79
RDX: 00000000ffffff72 RSI: 0000000020003c00 RDI: 0000000000000018
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 000000000000046d R14: 00000000006f8ad8 R15: 0000000000000000
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzk...@googlegroups.com.

syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.

[Jan Kara]

Hello,

This is a known problem I was speaking about here [1]. It is a generic
mm/fs problem but there's no solution to it yet. We'll discuss it at LSF/MM
next week so after that we may have some solution...

Honza

[1] https://www.spinics.net/lists/linux-xfs/msg14468.html

Jan Kara <ja...@suse.com>
SUSE Labs, CR

[syzbot]

syzbot has found a reproducer for the following crash on:

HEAD commit: 771c577c23ba Linux 4.17-rc6
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=108c9f37800000
kernel config: https://syzkaller.appspot.com/x/.config?x=982e2df1b9e60b02
dashboard link: https://syzkaller.appspot.com/bug?extid=9a44753ac327c557796a
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1655584f800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15134357800000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+9a4475...@syzkaller.appspotmail.com

WARNING: CPU: 0 PID: 4577 at fs/ext4/inode.c:3894
ext4_set_page_dirty+0x28d/0x330 fs/ext4/inode.c:3894

Kernel panic - not syncing: panic_on_warn set ...

CPU: 0 PID: 4577 Comm: syz-executor342 Not tainted 4.17.0-rc6+ #61

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:

__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
panic+0x22f/0x4de kernel/panic.c:184
__warn.cold.8+0x163/0x1b3 kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:ext4_set_page_dirty+0x28d/0x330 fs/ext4/inode.c:3894
RSP: 0018:ffff8801b38fe2a0 EFLAGS: 00010293
RAX: ffff8801aca16680 RBX: 1ffff1003671fc56 RCX: ffffffff82052441
RDX: 0000000000000000 RSI: ffffffff8205248d RDI: 0000000000000007
RBP: ffff8801b38fe378 R08: ffff8801aca16680 R09: 0000000000000006
R10: ffff8801aca16680 R11: 0000000000000000 R12: ffffea0007007f40
R13: 0000000000000000 R14: ffff8801b38fe350 R15: ffffea0007007f60
set_page_dirty+0x35f/0x6d0 mm/page-writeback.c:2566
set_page_dirty_lock+0x115/0x180 mm/page-writeback.c:2591
dio_bio_complete+0x599/0x870 fs/direct-io.c:559
dio_await_completion fs/direct-io.c:580 [inline]
do_blockdev_direct_IO+0x4153/0x9e90 fs/direct-io.c:1388
__blockdev_direct_IO+0x9d/0xc6 fs/direct-io.c:1417
ext4_direct_IO_read fs/ext4/inode.c:3833 [inline]
ext4_direct_IO+0xf90/0x2110 fs/ext4/inode.c:3865
generic_file_read_iter+0x510/0x2f00 mm/filemap.c:2341
ext4_file_read_iter+0x18b/0x3c0 fs/ext4/file.c:77
call_read_iter include/linux/fs.h:1778 [inline]
new_sync_read fs/read_write.c:406 [inline]
__vfs_read+0x696/0xa50 fs/read_write.c:418
vfs_read+0x17f/0x3d0 fs/read_write.c:452
ksys_pread64+0x174/0x1a0 fs/read_write.c:626
__do_sys_pread64 fs/read_write.c:636 [inline]
__se_sys_pread64 fs/read_write.c:633 [inline]
__x64_sys_pread64+0x97/0xf0 fs/read_write.c:633
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445c09
RSP: 002b:00007f4eead2ad18 EFLAGS: 00000246 ORIG_RAX: 0000000000000011
RAX: ffffffffffffffda RBX: 00000000006dac74 RCX: 0000000000445c09
RDX: 00000000fffffd80 RSI: 0000000020002000 RDI: 0000000000000073
RBP: 0000000000000000 R08: 65732f636f72702f R09: 65732f636f72702f
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dac70
R13: 00007f4eead2ad20 R14: 2e64657473757274 R15: 000000000000000b

[Jan Kara]

On Sun 20-05-18 23:07:02, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit: 771c577c23ba Linux 4.17-rc6
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=108c9f37800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=982e2df1b9e60b02
> dashboard link: https://syzkaller.appspot.com/bug?extid=9a44753ac327c557796a
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1655584f800000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15134357800000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+9a4475...@syzkaller.appspotmail.com
>
> WARNING: CPU: 0 PID: 4577 at fs/ext4/inode.c:3894
> ext4_set_page_dirty+0x28d/0x330 fs/ext4/inode.c:3894
> Kernel panic - not syncing: panic_on_warn set ...

Looking at the reproducer, this is the issue we have been speaking about at
LSF/MM - direct IO read dirties pages after writeback has written them out
and so we don't expect them to be dirtied. If someone told me I would not
believe this is possible to hit by fuzzing ;) Good job from the syzkaller
guys!

Honza

[Dmitry Vyukov]

Thanks, Jan! Very nice to hear.
I believe we are not yet at the limit of what's possible :)

[syzbot]

syzbot suspects this issue was fixed by commit:

commit 7dfbf8a07cf8c936b0d6cc810df6ae7923954d5b
Author: Chris Wilson <ch...@chris-wilson.co.uk>
Date: Tue Jun 30 15:27:24 2020 +0000

drm/i915: Skip stale object handle for debugfs per-file-stats

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=153d895f900000
start commit: 46cf053e Linux 5.5-rc3
git tree: upstream
kernel config: https://syzkaller.appspot.com/x/.config?x=ed9d672709340e35
dashboard link: https://syzkaller.appspot.com/bug?extid=9a44753ac327c557796a
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10055799e00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15b852c6e00000

If the result looks correct, please mark the issue as fixed by replying with:

#syz fix: drm/i915: Skip stale object handle for debugfs per-file-stats

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

[Theodore Ts'o]

#syz dup: WARNING in ext4_dirty_folio
#syz set subsystems: mm

ext4_set_page_dirty() was renamed to ext4_dirty_folio() in commit
e621900ad28b ("fs: Convert __set_page_dirty_buffers to
block_dirty_folio") in February 2022 --- which explains why it hasn't
reproduced in over 400 days,

(I assume marking it is the right thing to do, although the syzkaller
documentation doesn't explain exactly what happens after you mark the
report as a dup. The other possibility would be to marking it as
invalid, to drop this as noise. But that feels wrong, so I'm guessing
marking it as a dup is the best way to handle this kind of situation.)

I'm moving this to the mm subsystem, since the root cause is the
get_user_pages issue that has been with us for years, with discussions
as early as the 2018 LSF/MM.

- Ted