All of lore.kernel.org
 help / color / mirror / Atom feed
From: syzbot <syzbot+a6456f6334aa19425886@syzkaller.appspotmail.com>
To: akpm@linux-foundation.org, hughd@google.com,
	linux-kernel@vger.kernel.org,  linux-mm@kvack.org,
	syzkaller-bugs@googlegroups.com
Subject: [syzbot] [mm?] possible deadlock in upgrade_mmap_lock_carefully
Date: Sat, 28 Sep 2024 15:34:22 -0700	[thread overview]
Message-ID: <66f8846e.050a0220.aab67.000b.GAE@google.com> (raw)

Hello,

syzbot found the following issue on:

HEAD commit:    684a64bf32b6 Merge tag 'nfs-for-6.12-1' of git://git.linux..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11d9299f980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=bd75e1a00004094f
dashboard link: https://syzkaller.appspot.com/bug?extid=a6456f6334aa19425886
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40

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

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/72e96b8890d5/disk-684a64bf.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/27bdd881ea38/vmlinux-684a64bf.xz
kernel image: https://storage.googleapis.com/syzbot-assets/315166afeb3a/bzImage-684a64bf.xz

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

======================================================
WARNING: possible circular locking dependency detected
6.11.0-syzkaller-10547-g684a64bf32b6 #0 Not tainted
------------------------------------------------------
syz.3.2933/22916 is trying to acquire lock:
ffff88807bf96a18 (&mm->mmap_lock){++++}-{3:3}, at: mmap_write_lock_killable include/linux/mmap_lock.h:122 [inline]
ffff88807bf96a18 (&mm->mmap_lock){++++}-{3:3}, at: upgrade_mmap_lock_carefully+0xb6/0x160 mm/memory.c:6132

but task is already holding lock:
ffff888078651ce8 (&sb->s_type->i_mutex_key#12){+.+.}-{3:3}, at: inode_lock include/linux/fs.h:815 [inline]
ffff888078651ce8 (&sb->s_type->i_mutex_key#12){+.+.}-{3:3}, at: shmem_file_write_iter+0x80/0x120 mm/shmem.c:3211

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (&sb->s_type->i_mutex_key#12){+.+.}-{3:3}:
       lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5822
       down_write+0x99/0x220 kernel/locking/rwsem.c:1579
       inode_lock include/linux/fs.h:815 [inline]
       process_measurement+0x439/0x1fb0 security/integrity/ima/ima_main.c:250
       ima_file_mmap+0x13d/0x2b0 security/integrity/ima/ima_main.c:455
       security_mmap_file+0x7e7/0xa40 security/security.c:2977
       __do_sys_remap_file_pages mm/mmap.c:1692 [inline]
       __se_sys_remap_file_pages+0x6e6/0xa50 mm/mmap.c:1624
       do_syscall_x64 arch/x86/entry/common.c:52 [inline]
       do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
       entry_SYSCALL_64_after_hwframe+0x77/0x7f

-> #0 (&mm->mmap_lock){++++}-{3:3}:
       check_prev_add kernel/locking/lockdep.c:3158 [inline]
       check_prevs_add kernel/locking/lockdep.c:3277 [inline]
       validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3901
       __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5199
       lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5822
       down_write_killable+0xab/0x260 kernel/locking/rwsem.c:1590
       mmap_write_lock_killable include/linux/mmap_lock.h:122 [inline]
       upgrade_mmap_lock_carefully+0xb6/0x160 mm/memory.c:6132
       lock_mm_and_find_vma+0x107/0x2f0 mm/memory.c:6185
       do_user_addr_fault arch/x86/mm/fault.c:1361 [inline]
       handle_page_fault arch/x86/mm/fault.c:1481 [inline]
       exc_page_fault+0x1bf/0x8c0 arch/x86/mm/fault.c:1539
       asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623
       fault_in_readable+0x165/0x2b0
       fault_in_iov_iter_readable+0x229/0x280 lib/iov_iter.c:94
       generic_perform_write+0x259/0x6d0 mm/filemap.c:4040
       shmem_file_write_iter+0xf9/0x120 mm/shmem.c:3221
       new_sync_write fs/read_write.c:590 [inline]
       vfs_write+0xa6d/0xc90 fs/read_write.c:683
       ksys_write+0x183/0x2b0 fs/read_write.c:736
       do_syscall_x64 arch/x86/entry/common.c:52 [inline]
       do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
       entry_SYSCALL_64_after_hwframe+0x77/0x7f

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&sb->s_type->i_mutex_key#12);
                               lock(&mm->mmap_lock);
                               lock(&sb->s_type->i_mutex_key#12);
  lock(&mm->mmap_lock);

 *** DEADLOCK ***

3 locks held by syz.3.2933/22916:
 #0: ffff8880391b2478 (&f->f_pos_lock){+.+.}-{3:3}, at: fdget_pos+0x24e/0x320 fs/file.c:1187
 #1: ffff888043608420 (sb_writers#5){.+.+}-{0:0}, at: file_start_write include/linux/fs.h:2931 [inline]
 #1: ffff888043608420 (sb_writers#5){.+.+}-{0:0}, at: vfs_write+0x224/0xc90 fs/read_write.c:679
 #2: ffff888078651ce8 (&sb->s_type->i_mutex_key#12){+.+.}-{3:3}, at: inode_lock include/linux/fs.h:815 [inline]
 #2: ffff888078651ce8 (&sb->s_type->i_mutex_key#12){+.+.}-{3:3}, at: shmem_file_write_iter+0x80/0x120 mm/shmem.c:3211

stack backtrace:
CPU: 1 UID: 0 PID: 22916 Comm: syz.3.2933 Not tainted 6.11.0-syzkaller-10547-g684a64bf32b6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
 print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074
 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2203
 check_prev_add kernel/locking/lockdep.c:3158 [inline]
 check_prevs_add kernel/locking/lockdep.c:3277 [inline]
 validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3901
 __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5199
 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5822
 down_write_killable+0xab/0x260 kernel/locking/rwsem.c:1590
 mmap_write_lock_killable include/linux/mmap_lock.h:122 [inline]
 upgrade_mmap_lock_carefully+0xb6/0x160 mm/memory.c:6132
 lock_mm_and_find_vma+0x107/0x2f0 mm/memory.c:6185
 do_user_addr_fault arch/x86/mm/fault.c:1361 [inline]
 handle_page_fault arch/x86/mm/fault.c:1481 [inline]
 exc_page_fault+0x1bf/0x8c0 arch/x86/mm/fault.c:1539
 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623
RIP: 0010:fault_in_readable+0x165/0x2b0 mm/gup.c:2235
Code: b3 ff 4c 8d b3 ff 0f 00 00 48 89 d8 4d 01 e6 49 81 e6 00 f0 ff ff 49 39 c6 72 6b e8 95 cd b3 ff 4c 39 f3 74 6e 4c 89 64 24 10 <44> 8a 23 43 0f b6 04 2f 84 c0 75 18 44 88 64 24 40 48 81 c3 00 10
RSP: 0018:ffffc9000fa67a40 EFLAGS: 00050287
RAX: ffffffff81e0e7ab RBX: 0000000020001000 RCX: 0000000000040000
RDX: ffffc90004fa1000 RSI: 000000000000007d RDI: 000000000000007e
RBP: ffffc9000fa67af8 R08: ffffffff81e0e748 R09: ffffffff84b90999
R10: 0000000000000002 R11: ffff88805c679e00 R12: 000000000000fecc
R13: dffffc0000000000 R14: 0000000020010000 R15: 1ffff92001f4cf50
 fault_in_iov_iter_readable+0x229/0x280 lib/iov_iter.c:94
 generic_perform_write+0x259/0x6d0 mm/filemap.c:4040
 shmem_file_write_iter+0xf9/0x120 mm/shmem.c:3221
 new_sync_write fs/read_write.c:590 [inline]
 vfs_write+0xa6d/0xc90 fs/read_write.c:683
 ksys_write+0x183/0x2b0 fs/read_write.c:736
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fde8757def9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fde86fff038 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007fde87735f80 RCX: 00007fde8757def9
RDX: 000000000000fecc RSI: 0000000020000100 RDI: 0000000000000003
RBP: 00007fde875f0b76 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007fde87735f80 R15: 00007fde8785fa28
 </TASK>
----------------
Code disassembly (best guess):
   0:	b3 ff                	mov    $0xff,%bl
   2:	4c 8d b3 ff 0f 00 00 	lea    0xfff(%rbx),%r14
   9:	48 89 d8             	mov    %rbx,%rax
   c:	4d 01 e6             	add    %r12,%r14
   f:	49 81 e6 00 f0 ff ff 	and    $0xfffffffffffff000,%r14
  16:	49 39 c6             	cmp    %rax,%r14
  19:	72 6b                	jb     0x86
  1b:	e8 95 cd b3 ff       	call   0xffb3cdb5
  20:	4c 39 f3             	cmp    %r14,%rbx
  23:	74 6e                	je     0x93
  25:	4c 89 64 24 10       	mov    %r12,0x10(%rsp)
* 2a:	44 8a 23             	mov    (%rbx),%r12b <-- trapping instruction
  2d:	43 0f b6 04 2f       	movzbl (%r15,%r13,1),%eax
  32:	84 c0                	test   %al,%al
  34:	75 18                	jne    0x4e
  36:	44 88 64 24 40       	mov    %r12b,0x40(%rsp)
  3b:	48                   	rex.W
  3c:	81                   	.byte 0x81
  3d:	c3                   	ret
  3e:	00 10                	add    %dl,(%rax)


---
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 syzkaller@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


             reply	other threads:[~2024-09-28 22:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-28 22:34 syzbot [this message]
2024-10-01 18:46 ` [syzbot] [mm?] possible deadlock in upgrade_mmap_lock_carefully syzbot
2024-10-02  4:48 ` syzbot
2024-10-02 12:14   ` Shu Han
2024-10-03  1:32     ` Paul Moore
2024-10-03  1:32       ` syzbot
2024-10-03  2:52         ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=66f8846e.050a0220.aab67.000b.GAE@google.com \
    --to=syzbot+a6456f6334aa19425886@syzkaller.appspotmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.