All of lore.kernel.org
 help / color / mirror / Atom feed
From: syzbot <syzbot+c1751b6739d83d70bb75@syzkaller.appspotmail.com>
To: almaz.alexandrovich@paragon-software.com,
	linux-kernel@vger.kernel.org,  ntfs3@lists.linux.dev,
	syzkaller-bugs@googlegroups.com
Subject: [syzbot] [ntfs3?] possible deadlock in ntfs_file_mmap
Date: Sat, 15 Jun 2024 00:17:25 -0700	[thread overview]
Message-ID: <0000000000002488fc061ae886f8@google.com> (raw)

Hello,

syzbot found the following issue on:

HEAD commit:    a957267fa7e9 Add linux-next specific files for 20240611
git tree:       linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1139caa2980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=9a880e96898e79f8
dashboard link: https://syzkaller.appspot.com/bug?extid=c1751b6739d83d70bb75
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/6451759a606b/disk-a957267f.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/7f635dbe5b8a/vmlinux-a957267f.xz
kernel image: https://storage.googleapis.com/syzbot-assets/33eafd1b8aec/bzImage-a957267f.xz

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

loop0: detected capacity change from 0 to 4096
ntfs3: loop0: Different NTFS sector size (4096) and media sector size (512).
======================================================
WARNING: possible circular locking dependency detected
6.10.0-rc3-next-20240611-syzkaller #0 Not tainted
------------------------------------------------------
syz-executor.0/9000 is trying to acquire lock:
ffff88805b15dbb8 (&sb->s_type->i_mutex_key#21){+.+.}-{3:3}, at: inode_lock include/linux/fs.h:795 [inline]
ffff88805b15dbb8 (&sb->s_type->i_mutex_key#21){+.+.}-{3:3}, at: ntfs_file_mmap+0x5d8/0x860 fs/ntfs3/file.c:302

but task is already holding lock:
ffff88807d087398 (&mm->mmap_lock){++++}-{3:3}, at: mmap_write_lock_killable include/linux/mmap_lock.h:122 [inline]
ffff88807d087398 (&mm->mmap_lock){++++}-{3:3}, at: vm_mmap_pgoff+0x17c/0x3d0 mm/util.c:571

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (&mm->mmap_lock){++++}-{3:3}:
       lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5817
       gup_fast_fallback+0x24c/0x2b40 mm/gup.c:3534
       pin_user_pages_fast+0xcc/0x160 mm/gup.c:3658
       iov_iter_extract_user_pages lib/iov_iter.c:1583 [inline]
       iov_iter_extract_pages+0x3db/0x720 lib/iov_iter.c:1646
       dio_refill_pages fs/direct-io.c:173 [inline]
       dio_get_page fs/direct-io.c:214 [inline]
       do_direct_IO fs/direct-io.c:916 [inline]
       __blockdev_direct_IO+0x150f/0x49d0 fs/direct-io.c:1249
       blockdev_direct_IO include/linux/fs.h:3201 [inline]
       ntfs_direct_IO+0x195/0x370 fs/ntfs3/inode.c:803
       generic_file_direct_write+0x130/0x350 mm/filemap.c:3941
       __generic_file_write_iter+0x129/0x230 mm/filemap.c:4097
       ntfs_file_write_iter+0x68f/0x770 fs/ntfs3/file.c:1126
       new_sync_write fs/read_write.c:497 [inline]
       vfs_write+0xa72/0xc90 fs/read_write.c:590
       ksys_write+0x1a0/0x2c0 fs/read_write.c:643
       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 (&sb->s_type->i_mutex_key#21){+.+.}-{3:3}:
       check_prev_add kernel/locking/lockdep.c:3159 [inline]
       check_prevs_add kernel/locking/lockdep.c:3278 [inline]
       validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3902
       __lock_acquire+0x1359/0x2000 kernel/locking/lockdep.c:5194
       lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5817
       down_write+0x3a/0x50 kernel/locking/rwsem.c:1579
       inode_lock include/linux/fs.h:795 [inline]
       ntfs_file_mmap+0x5d8/0x860 fs/ntfs3/file.c:302
       call_mmap include/linux/fs.h:2123 [inline]
       mmap_region+0xe8f/0x2090 mm/mmap.c:2927
       do_mmap+0x8ad/0xfa0 mm/mmap.c:1438
       vm_mmap_pgoff+0x1dd/0x3d0 mm/util.c:573
       ksys_mmap_pgoff+0x4f1/0x720 mm/mmap.c:1484
       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(&mm->mmap_lock);
                               lock(&sb->s_type->i_mutex_key#21);
                               lock(&mm->mmap_lock);
  lock(&sb->s_type->i_mutex_key#21);

 *** DEADLOCK ***

1 lock held by syz-executor.0/9000:
 #0: ffff88807d087398 (&mm->mmap_lock){++++}-{3:3}, at: mmap_write_lock_killable include/linux/mmap_lock.h:122 [inline]
 #0: ffff88807d087398 (&mm->mmap_lock){++++}-{3:3}, at: vm_mmap_pgoff+0x17c/0x3d0 mm/util.c:571

stack backtrace:
CPU: 0 PID: 9000 Comm: syz-executor.0 Not tainted 6.10.0-rc3-next-20240611-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:91 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:117
 print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2075
 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2204
 check_prev_add kernel/locking/lockdep.c:3159 [inline]
 check_prevs_add kernel/locking/lockdep.c:3278 [inline]
 validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3902
 __lock_acquire+0x1359/0x2000 kernel/locking/lockdep.c:5194
 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5817
 down_write+0x3a/0x50 kernel/locking/rwsem.c:1579
 inode_lock include/linux/fs.h:795 [inline]
 ntfs_file_mmap+0x5d8/0x860 fs/ntfs3/file.c:302
 call_mmap include/linux/fs.h:2123 [inline]
 mmap_region+0xe8f/0x2090 mm/mmap.c:2927
 do_mmap+0x8ad/0xfa0 mm/mmap.c:1438
 vm_mmap_pgoff+0x1dd/0x3d0 mm/util.c:573
 ksys_mmap_pgoff+0x4f1/0x720 mm/mmap.c:1484
 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:0x7f7e2707cea9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 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 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f7e27de60c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000009
RAX: ffffffffffffffda RBX: 00007f7e271b3f80 RCX: 00007f7e2707cea9
RDX: 00000000007fffff RSI: 0000000000003000 RDI: 0000000020000000
RBP: 00007f7e270ebff4 R08: 0000000000000004 R09: 0000000000000000
R10: 0000000000000012 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007f7e271b3f80 R15: 00007ffee8137f98
 </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 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-06-15  7:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-15  7:17 syzbot [this message]
2024-07-27 13:44 ` [syzbot] [ntfs3?] possible deadlock in ntfs_file_mmap syzbot
2024-07-27 22:40   ` Hillf Danton
2024-07-27 23:03     ` syzbot
2024-07-27 21:30 ` syzbot

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=0000000000002488fc061ae886f8@google.com \
    --to=syzbot+c1751b6739d83d70bb75@syzkaller.appspotmail.com \
    --cc=almaz.alexandrovich@paragon-software.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ntfs3@lists.linux.dev \
    --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.