[v5.15] possible deadlock in do_page_mkwrite
0 views
Skip to first unread message
syzbot
Jun 11, 2023, 8:09:51 PM6/11/23
to syzkaller...@googlegroups.com
Hello,
syzbot found the following issue on:
HEAD commit: 7349e40704a0 Linux 5.15.116
git tree: linux-5.15.y
console output: https://syzkaller.appspot.com/x/log.txt?x=15375807280000
kernel config: https://syzkaller.appspot.com/x/.config?x=831c3122ac9c9145
dashboard link: https://syzkaller.appspot.com/bug?extid=734fef9ab106cbaa9556
compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17bef9b3280000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11c10c8b280000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/8c03c3ad4501/disk-7349e407.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/350c3d79bc87/vmlinux-7349e407.xz
kernel image: https://storage.googleapis.com/syzbot-assets/73a4ed3d5438/bzImage-7349e407.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/ca57204c07da/mount_0.gz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+734fef...@syzkaller.appspotmail.com
REISERFS (device loop0): Created .reiserfs_priv - reserved for xattr storage.
======================================================
WARNING: possible circular locking dependency detected
5.15.116-syzkaller #0 Not tainted
------------------------------------------------------
syz-executor355/3626 is trying to acquire lock:
ffff88814717f090 (&sbi->lock){+.+.}-{3:3}, at: reiserfs_write_lock+0x76/0xd0 fs/reiserfs/lock.c:27
but task is already holding lock:
ffff88807b7fc558 (sb_pagefaults){.+.+}-{0:0}, at: do_page_mkwrite+0x1a9/0x440 mm/memory.c:2883
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (sb_pagefaults){.+.+}-{0:0}:
lock_acquire+0x1db/0x4f0 kernel/locking/lockdep.c:5622
percpu_down_read include/linux/percpu-rwsem.h:51 [inline]
__sb_start_write include/linux/fs.h:1742 [inline]
sb_start_pagefault include/linux/fs.h:1841 [inline]
filemap_page_mkwrite+0x11b/0x650 mm/filemap.c:3358
do_page_mkwrite+0x1a9/0x440 mm/memory.c:2883
do_shared_fault mm/memory.c:4285 [inline]
do_fault mm/memory.c:4353 [inline]
handle_pte_fault mm/memory.c:4608 [inline]
__handle_mm_fault mm/memory.c:4743 [inline]
handle_mm_fault+0x2803/0x5950 mm/memory.c:4841
do_user_addr_fault arch/x86/mm/fault.c:1397 [inline]
handle_page_fault arch/x86/mm/fault.c:1485 [inline]
exc_page_fault+0x271/0x740 arch/x86/mm/fault.c:1541
asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:568
-> #1 (&mm->mmap_lock#2){++++}-{3:3}:
lock_acquire+0x1db/0x4f0 kernel/locking/lockdep.c:5622
__might_fault+0xb4/0x110 mm/memory.c:5311
reiserfs_ioctl+0x11d/0x340 fs/reiserfs/ioctl.c:96
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl+0xf1/0x160 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x61/0xcb
-> #0 (
&sbi->lock){+.+.}-{3:3}:
check_prev_add kernel/locking/lockdep.c:3053 [inline]
check_prevs_add kernel/locking/lockdep.c:3172 [inline]
validate_chain+0x1646/0x58b0 kernel/locking/lockdep.c:3787
__lock_acquire+0x1295/0x1ff0 kernel/locking/lockdep.c:5011
lock_acquire+0x1db/0x4f0 kernel/locking/lockdep.c:5622
__mutex_lock_common+0x1da/0x25a0 kernel/locking/mutex.c:596
__mutex_lock kernel/locking/mutex.c:729 [inline]
mutex_lock_nested+0x17/0x20 kernel/locking/mutex.c:743
reiserfs_write_lock+0x76/0xd0 fs/reiserfs/lock.c:27
reiserfs_dirty_inode+0xee/0x240 fs/reiserfs/super.c:704
__mark_inode_dirty+0x2fd/0xd60 fs/fs-writeback.c:2442
generic_update_time+0x1cb/0x1e0 fs/inode.c:1775
inode_update_time fs/inode.c:1788 [inline]
file_update_time+0x3eb/0x460 fs/inode.c:1977
filemap_page_mkwrite+0x222/0x650 mm/filemap.c:3359
do_page_mkwrite+0x1a9/0x440 mm/memory.c:2883
do_shared_fault mm/memory.c:4285 [inline]
do_fault mm/memory.c:4353 [inline]
handle_pte_fault mm/memory.c:4608 [inline]
__handle_mm_fault mm/memory.c:4743 [inline]
handle_mm_fault+0x2803/0x5950 mm/memory.c:4841
do_user_addr_fault arch/x86/mm/fault.c:1397 [inline]
handle_page_fault arch/x86/mm/fault.c:1485 [inline]
exc_page_fault+0x271/0x740 arch/x86/mm/fault.c:1541
asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:568
other info that might help us debug this:
Chain exists of:
&sbi->lock --> &mm->mmap_lock#2 --> sb_pagefaults
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(sb_pagefaults);
lock(&mm->mmap_lock#2);
lock(sb_pagefaults);
lock(&sbi->lock);
*** DEADLOCK ***
2 locks held by syz-executor355/3626:
#0: ffff8880208a2b28 (
&mm->mmap_lock#2){++++}-{3:3}, at: mmap_read_lock+0x1c/0x50 include/linux/mmap_lock.h:117
#1: ffff88807b7fc558 (sb_pagefaults){.+.+}-{0:0}, at: do_page_mkwrite+0x1a9/0x440 mm/memory.c:2883
stack backtrace:
CPU: 0 PID: 3626 Comm: syz-executor355 Not tainted 5.15.116-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106
check_noncircular+0x2f8/0x3b0 kernel/locking/lockdep.c:2133
check_prev_add kernel/locking/lockdep.c:3053 [inline]
check_prevs_add kernel/locking/lockdep.c:3172 [inline]
validate_chain+0x1646/0x58b0 kernel/locking/lockdep.c:3787
__lock_acquire+0x1295/0x1ff0 kernel/locking/lockdep.c:5011
lock_acquire+0x1db/0x4f0 kernel/locking/lockdep.c:5622
__mutex_lock_common+0x1da/0x25a0 kernel/locking/mutex.c:596
__mutex_lock kernel/locking/mutex.c:729 [inline]
mutex_lock_nested+0x17/0x20 kernel/locking/mutex.c:743
reiserfs_write_lock+0x76/0xd0 fs/reiserfs/lock.c:27
reiserfs_dirty_inode+0xee/0x240 fs/reiserfs/super.c:704
__mark_inode_dirty+0x2fd/0xd60 fs/fs-writeback.c:2442
generic_update_time+0x1cb/0x1e0 fs/inode.c:1775
inode_update_time fs/inode.c:1788 [inline]
file_update_time+0x3eb/0x460 fs/inode.c:1977
filemap_page_mkwrite+0x222/0x650 mm/filemap.c:3359
do_page_mkwrite+0x1a9/0x440 mm/memory.c:2883
do_shared_fault mm/memory.c:4285 [inline]
do_fault mm/memory.c:4353 [inline]
handle_pte_fault mm/memory.c:4608 [inline]
__handle_mm_fault mm/memory.c:4743 [inline]
handle_mm_fault+0x2803/0x5950 mm/memory.c:4841
do_user_addr_fault arch/x86/mm/fault.c:1397 [inline]
handle_page_fault arch/x86/mm/fault.c:1485 [inline]
exc_page_fault+0x271/0x740 arch/x86/mm/fault.c:1541
asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:568
RIP: 0033:0x7fef3805b506
Code: 00 e8 ee fe 04 00 48 83 f8 ff 0f 84 3c ff ff ff 48 89 05 85 bc 0c 00 e9 30 ff ff ff be 73 00 00 00 31 c9 31 c0 ba 42 da 14 00 <66> 89 34 25 c4 00 00 20 bf 02 00 00 00 be c0 00 00 20 c7 04 25 c0
RSP: 002b:00007fef3804f300 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00007fef381297c0 RCX: 0000000000000000
RDX: 000000000014da42 RSI: 0000000000000073 RDI: 00007fef381297cc
RBP: 00007fef380f6278 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fef380f5180
R13: 0030656c69662f2e R14: 7366726573696572 R15: 00007fef381297c8
</TASK>
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the bug is already fixed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to change bug's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the bug is a duplicate of another bug, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
syzbot found the following issue on:
HEAD commit: 7349e40704a0 Linux 5.15.116
git tree: linux-5.15.y
console output: https://syzkaller.appspot.com/x/log.txt?x=15375807280000
kernel config: https://syzkaller.appspot.com/x/.config?x=831c3122ac9c9145
dashboard link: https://syzkaller.appspot.com/bug?extid=734fef9ab106cbaa9556
compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17bef9b3280000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11c10c8b280000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/8c03c3ad4501/disk-7349e407.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/350c3d79bc87/vmlinux-7349e407.xz
kernel image: https://storage.googleapis.com/syzbot-assets/73a4ed3d5438/bzImage-7349e407.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/ca57204c07da/mount_0.gz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+734fef...@syzkaller.appspotmail.com
REISERFS (device loop0): Created .reiserfs_priv - reserved for xattr storage.
======================================================
WARNING: possible circular locking dependency detected
5.15.116-syzkaller #0 Not tainted
------------------------------------------------------
syz-executor355/3626 is trying to acquire lock:
ffff88814717f090 (&sbi->lock){+.+.}-{3:3}, at: reiserfs_write_lock+0x76/0xd0 fs/reiserfs/lock.c:27
but task is already holding lock:
ffff88807b7fc558 (sb_pagefaults){.+.+}-{0:0}, at: do_page_mkwrite+0x1a9/0x440 mm/memory.c:2883
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (sb_pagefaults){.+.+}-{0:0}:
lock_acquire+0x1db/0x4f0 kernel/locking/lockdep.c:5622
percpu_down_read include/linux/percpu-rwsem.h:51 [inline]
__sb_start_write include/linux/fs.h:1742 [inline]
sb_start_pagefault include/linux/fs.h:1841 [inline]
filemap_page_mkwrite+0x11b/0x650 mm/filemap.c:3358
do_page_mkwrite+0x1a9/0x440 mm/memory.c:2883
do_shared_fault mm/memory.c:4285 [inline]
do_fault mm/memory.c:4353 [inline]
handle_pte_fault mm/memory.c:4608 [inline]
__handle_mm_fault mm/memory.c:4743 [inline]
handle_mm_fault+0x2803/0x5950 mm/memory.c:4841
do_user_addr_fault arch/x86/mm/fault.c:1397 [inline]
handle_page_fault arch/x86/mm/fault.c:1485 [inline]
exc_page_fault+0x271/0x740 arch/x86/mm/fault.c:1541
asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:568
-> #1 (&mm->mmap_lock#2){++++}-{3:3}:
lock_acquire+0x1db/0x4f0 kernel/locking/lockdep.c:5622
__might_fault+0xb4/0x110 mm/memory.c:5311
reiserfs_ioctl+0x11d/0x340 fs/reiserfs/ioctl.c:96
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl+0xf1/0x160 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x61/0xcb
-> #0 (
&sbi->lock){+.+.}-{3:3}:
check_prev_add kernel/locking/lockdep.c:3053 [inline]
check_prevs_add kernel/locking/lockdep.c:3172 [inline]
validate_chain+0x1646/0x58b0 kernel/locking/lockdep.c:3787
__lock_acquire+0x1295/0x1ff0 kernel/locking/lockdep.c:5011
lock_acquire+0x1db/0x4f0 kernel/locking/lockdep.c:5622
__mutex_lock_common+0x1da/0x25a0 kernel/locking/mutex.c:596
__mutex_lock kernel/locking/mutex.c:729 [inline]
mutex_lock_nested+0x17/0x20 kernel/locking/mutex.c:743
reiserfs_write_lock+0x76/0xd0 fs/reiserfs/lock.c:27
reiserfs_dirty_inode+0xee/0x240 fs/reiserfs/super.c:704
__mark_inode_dirty+0x2fd/0xd60 fs/fs-writeback.c:2442
generic_update_time+0x1cb/0x1e0 fs/inode.c:1775
inode_update_time fs/inode.c:1788 [inline]
file_update_time+0x3eb/0x460 fs/inode.c:1977
filemap_page_mkwrite+0x222/0x650 mm/filemap.c:3359
do_page_mkwrite+0x1a9/0x440 mm/memory.c:2883
do_shared_fault mm/memory.c:4285 [inline]
do_fault mm/memory.c:4353 [inline]
handle_pte_fault mm/memory.c:4608 [inline]
__handle_mm_fault mm/memory.c:4743 [inline]
handle_mm_fault+0x2803/0x5950 mm/memory.c:4841
do_user_addr_fault arch/x86/mm/fault.c:1397 [inline]
handle_page_fault arch/x86/mm/fault.c:1485 [inline]
exc_page_fault+0x271/0x740 arch/x86/mm/fault.c:1541
asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:568
other info that might help us debug this:
Chain exists of:
&sbi->lock --> &mm->mmap_lock#2 --> sb_pagefaults
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(sb_pagefaults);
lock(&mm->mmap_lock#2);
lock(sb_pagefaults);
lock(&sbi->lock);
*** DEADLOCK ***
2 locks held by syz-executor355/3626:
#0: ffff8880208a2b28 (
&mm->mmap_lock#2){++++}-{3:3}, at: mmap_read_lock+0x1c/0x50 include/linux/mmap_lock.h:117
#1: ffff88807b7fc558 (sb_pagefaults){.+.+}-{0:0}, at: do_page_mkwrite+0x1a9/0x440 mm/memory.c:2883
stack backtrace:
CPU: 0 PID: 3626 Comm: syz-executor355 Not tainted 5.15.116-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106
check_noncircular+0x2f8/0x3b0 kernel/locking/lockdep.c:2133
check_prev_add kernel/locking/lockdep.c:3053 [inline]
check_prevs_add kernel/locking/lockdep.c:3172 [inline]
validate_chain+0x1646/0x58b0 kernel/locking/lockdep.c:3787
__lock_acquire+0x1295/0x1ff0 kernel/locking/lockdep.c:5011
lock_acquire+0x1db/0x4f0 kernel/locking/lockdep.c:5622
__mutex_lock_common+0x1da/0x25a0 kernel/locking/mutex.c:596
__mutex_lock kernel/locking/mutex.c:729 [inline]
mutex_lock_nested+0x17/0x20 kernel/locking/mutex.c:743
reiserfs_write_lock+0x76/0xd0 fs/reiserfs/lock.c:27
reiserfs_dirty_inode+0xee/0x240 fs/reiserfs/super.c:704
__mark_inode_dirty+0x2fd/0xd60 fs/fs-writeback.c:2442
generic_update_time+0x1cb/0x1e0 fs/inode.c:1775
inode_update_time fs/inode.c:1788 [inline]
file_update_time+0x3eb/0x460 fs/inode.c:1977
filemap_page_mkwrite+0x222/0x650 mm/filemap.c:3359
do_page_mkwrite+0x1a9/0x440 mm/memory.c:2883
do_shared_fault mm/memory.c:4285 [inline]
do_fault mm/memory.c:4353 [inline]
handle_pte_fault mm/memory.c:4608 [inline]
__handle_mm_fault mm/memory.c:4743 [inline]
handle_mm_fault+0x2803/0x5950 mm/memory.c:4841
do_user_addr_fault arch/x86/mm/fault.c:1397 [inline]
handle_page_fault arch/x86/mm/fault.c:1485 [inline]
exc_page_fault+0x271/0x740 arch/x86/mm/fault.c:1541
asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:568
RIP: 0033:0x7fef3805b506
Code: 00 e8 ee fe 04 00 48 83 f8 ff 0f 84 3c ff ff ff 48 89 05 85 bc 0c 00 e9 30 ff ff ff be 73 00 00 00 31 c9 31 c0 ba 42 da 14 00 <66> 89 34 25 c4 00 00 20 bf 02 00 00 00 be c0 00 00 20 c7 04 25 c0
RSP: 002b:00007fef3804f300 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00007fef381297c0 RCX: 0000000000000000
RDX: 000000000014da42 RSI: 0000000000000073 RDI: 00007fef381297cc
RBP: 00007fef380f6278 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fef380f5180
R13: 0030656c69662f2e R14: 7366726573696572 R15: 00007fef381297c8
</TASK>
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the bug is already fixed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to change bug's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the bug is a duplicate of another bug, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
Reply all
Reply to author
Forward
0 new messages