[v6.6] possible deadlock in do_page_mkwrite

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 8cee53b8eaeb Linux 6.6.134
git tree: linux-6.6.y
console output: https://syzkaller.appspot.com/x/log.txt?x=116c5036580000
kernel config: https://syzkaller.appspot.com/x/.config?x=c5b35c4db8465904
dashboard link: https://syzkaller.appspot.com/bug?extid=958ab8b25a039ffeb917
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/4c0eb6df7b4a/disk-8cee53b8.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/38626ee912e4/vmlinux-8cee53b8.xz
kernel image: https://storage.googleapis.com/syzbot-assets/646a84f3433a/bzImage-8cee53b8.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+958ab8...@syzkaller.appspotmail.com

======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
syz.1.1013/10309 is trying to acquire lock:
ffff888026a15090 (&sbi->lock){+.+.}-{3:3}, at: reiserfs_write_lock+0x79/0xd0 fs/reiserfs/lock.c:27

but task is already holding lock:
ffff88806576e510 (sb_pagefaults#4){.+.+}-{0:0}, at: do_page_mkwrite+0x153/0x3e0 mm/memory.c:2951

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 (sb_pagefaults#4){.+.+}-{0:0}:
percpu_down_read include/linux/percpu-rwsem.h:51 [inline]
__sb_start_write include/linux/fs.h:1633 [inline]
sb_start_pagefault include/linux/fs.h:1737 [inline]
filemap_page_mkwrite+0x161/0x650 mm/filemap.c:3690
do_page_mkwrite+0x153/0x3e0 mm/memory.c:2951
wp_page_shared mm/memory.c:3311 [inline]
do_wp_page+0xdff/0x35f0 mm/memory.c:3396
handle_pte_fault mm/memory.c:5063 [inline]
__handle_mm_fault mm/memory.c:5188 [inline]
handle_mm_fault+0x135d/0x4c00 mm/memory.c:5353
do_user_addr_fault+0x730/0x12c0 arch/x86/mm/fault.c:1371
handle_page_fault arch/x86/mm/fault.c:1463 [inline]
exc_page_fault+0x64/0x100 arch/x86/mm/fault.c:1516
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:608

-> #1 (&mm->mmap_lock){++++}-{3:3}:
__might_fault+0xc6/0x120 mm/memory.c:5968
reiserfs_ioctl+0x143/0x2d0 fs/reiserfs/ioctl.c:96
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:871 [inline]
__se_sys_ioctl+0xfd/0x170 fs/ioctl.c:857
do_syscall_x64 arch/x86/entry/common.c:46 [inline]
do_syscall_64+0x55/0xa0 arch/x86/entry/common.c:76
entry_SYSCALL_64_after_hwframe+0x68/0xd2

-> #0 (&sbi->lock){+.+.}-{3:3}:
check_prev_add kernel/locking/lockdep.c:3134 [inline]
check_prevs_add kernel/locking/lockdep.c:3253 [inline]
validate_chain kernel/locking/lockdep.c:3869 [inline]
__lock_acquire+0x2df1/0x7d40 kernel/locking/lockdep.c:5137
lock_acquire+0x19e/0x420 kernel/locking/lockdep.c:5754
__mutex_lock_common kernel/locking/mutex.c:603 [inline]
__mutex_lock+0x136/0xcc0 kernel/locking/mutex.c:747
reiserfs_write_lock+0x79/0xd0 fs/reiserfs/lock.c:27
reiserfs_dirty_inode+0x111/0x270 fs/reiserfs/super.c:704
__mark_inode_dirty+0x2cc/0xc90 fs/fs-writeback.c:2471
generic_update_time fs/inode.c:1981 [inline]
inode_update_time fs/inode.c:1994 [inline]
__file_update_time fs/inode.c:2180 [inline]
file_update_time+0x187/0x1a0 fs/inode.c:2210
filemap_page_mkwrite+0x28b/0x650 mm/filemap.c:3691
do_page_mkwrite+0x153/0x3e0 mm/memory.c:2951
wp_page_shared mm/memory.c:3311 [inline]
do_wp_page+0xdff/0x35f0 mm/memory.c:3396
handle_pte_fault mm/memory.c:5063 [inline]
__handle_mm_fault mm/memory.c:5188 [inline]
handle_mm_fault+0x135d/0x4c00 mm/memory.c:5353
do_user_addr_fault+0x730/0x12c0 arch/x86/mm/fault.c:1371
handle_page_fault arch/x86/mm/fault.c:1463 [inline]
exc_page_fault+0x64/0x100 arch/x86/mm/fault.c:1516
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:608

other info that might help us debug this:

Chain exists of:
&sbi->lock --> &mm->mmap_lock --> sb_pagefaults#4

Possible unsafe locking scenario:

CPU0 CPU1
---- ----
rlock(sb_pagefaults#4);
lock(&mm->mmap_lock);
lock(sb_pagefaults#4);
lock(&sbi->lock);

*** DEADLOCK ***

2 locks held by syz.1.1013/10309:
#0: ffff88802ea49e20 (&mm->mmap_lock){++++}-{3:3}, at: mmap_read_trylock include/linux/mmap_lock.h:165 [inline]
#0: ffff88802ea49e20 (&mm->mmap_lock){++++}-{3:3}, at: get_mmap_lock_carefully mm/memory.c:5380 [inline]
#0: ffff88802ea49e20 (&mm->mmap_lock){++++}-{3:3}, at: lock_mm_and_find_vma+0x32/0x2f0 mm/memory.c:5440
#1: ffff88806576e510 (sb_pagefaults#4){.+.+}-{0:0}, at: do_page_mkwrite+0x153/0x3e0 mm/memory.c:2951

stack backtrace:
CPU: 0 PID: 10309 Comm: syz.1.1013 Not tainted syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
Call Trace:
<TASK>
dump_stack_lvl+0x18c/0x250 lib/dump_stack.c:106
check_noncircular+0x2fc/0x400 kernel/locking/lockdep.c:2187
check_prev_add kernel/locking/lockdep.c:3134 [inline]
check_prevs_add kernel/locking/lockdep.c:3253 [inline]
validate_chain kernel/locking/lockdep.c:3869 [inline]
__lock_acquire+0x2df1/0x7d40 kernel/locking/lockdep.c:5137
lock_acquire+0x19e/0x420 kernel/locking/lockdep.c:5754
__mutex_lock_common kernel/locking/mutex.c:603 [inline]
__mutex_lock+0x136/0xcc0 kernel/locking/mutex.c:747
reiserfs_write_lock+0x79/0xd0 fs/reiserfs/lock.c:27
reiserfs_dirty_inode+0x111/0x270 fs/reiserfs/super.c:704
__mark_inode_dirty+0x2cc/0xc90 fs/fs-writeback.c:2471
generic_update_time fs/inode.c:1981 [inline]
inode_update_time fs/inode.c:1994 [inline]
__file_update_time fs/inode.c:2180 [inline]
file_update_time+0x187/0x1a0 fs/inode.c:2210
filemap_page_mkwrite+0x28b/0x650 mm/filemap.c:3691
do_page_mkwrite+0x153/0x3e0 mm/memory.c:2951
wp_page_shared mm/memory.c:3311 [inline]
do_wp_page+0xdff/0x35f0 mm/memory.c:3396
handle_pte_fault mm/memory.c:5063 [inline]
__handle_mm_fault mm/memory.c:5188 [inline]
handle_mm_fault+0x135d/0x4c00 mm/memory.c:5353
do_user_addr_fault+0x730/0x12c0 arch/x86/mm/fault.c:1371
handle_page_fault arch/x86/mm/fault.c:1463 [inline]
exc_page_fault+0x64/0x100 arch/x86/mm/fault.c:1516
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:608
RIP: 0033:0x7fe998b6b6d8
Code: fc 89 37 c3 c5 fa 6f 06 c5 fa 6f 4c 16 f0 c5 fa 7f 07 c5 fa 7f 4c 17 f0 c3 66 0f 1f 84 00 00 00 00 00 48 8b 4c 16 f8 48 8b 36 <48> 89 37 48 89 4c 17 f8 c3 c5 fe 6f 54 16 e0 c5 fe 6f 5c 16 c0 c5
RSP: 002b:00007ffe2d8da978 EFLAGS: 00010246
RAX: 0000200000000040 RBX: 0000000000000004 RCX: 0031656c69662f2e
RDX: 0000000000000008 RSI: 0031656c69662f2e RDI: 0000200000000040
RBP: fffffffffffffffe R08: 0000001b2c420000 R09: 0000000000000001
R10: 7ffffffffffffff7 R11: 0000000000000009 R12: 00007ffe2d8daaa0
R13: 00007fe998e1609c R14: 00000000000699b5 R15: 00007fe998e16090
</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 report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup