aboutsummaryrefslogtreecommitdiff
path: root/lib/memory-notifier-error-inject.c
diff options
context:
space:
mode:
authorSungjong Seo <[email protected]>2023-07-14 17:43:54 +0900
committerNamjae Jeon <[email protected]>2023-07-15 08:34:19 +0900
commitff84772fd45d486e4fc78c82e2f70ce5333543e6 (patch)
treebd455f7000cbc714dfc1e7749fef0ffdfbc7fc38 /lib/memory-notifier-error-inject.c
parentd42334578eba1390859012ebb91e1e556d51db49 (diff)
exfat: release s_lock before calling dir_emit()
There is a potential deadlock reported by syzbot as below: ====================================================== WARNING: possible circular locking dependency detected 6.4.0-next-20230707-syzkaller #0 Not tainted ------------------------------------------------------ syz-executor330/5073 is trying to acquire lock: ffff8880218527a0 (&mm->mmap_lock){++++}-{3:3}, at: mmap_read_lock_killable include/linux/mmap_lock.h:151 [inline] ffff8880218527a0 (&mm->mmap_lock){++++}-{3:3}, at: get_mmap_lock_carefully mm/memory.c:5293 [inline] ffff8880218527a0 (&mm->mmap_lock){++++}-{3:3}, at: lock_mm_and_find_vma+0x369/0x510 mm/memory.c:5344 but task is already holding lock: ffff888019f760e0 (&sbi->s_lock){+.+.}-{3:3}, at: exfat_iterate+0x117/0xb50 fs/exfat/dir.c:232 which lock already depends on the new lock. Chain exists of: &mm->mmap_lock --> mapping.invalidate_lock#3 --> &sbi->s_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&sbi->s_lock); lock(mapping.invalidate_lock#3); lock(&sbi->s_lock); rlock(&mm->mmap_lock); Let's try to avoid above potential deadlock condition by moving dir_emit*() out of sbi->s_lock coverage. Fixes: ca06197382bd ("exfat: add directory operations") Cc: [email protected] #v5.7+ Reported-by: [email protected] Link: https://lore.kernel.org/lkml/[email protected]/T/#u Tested-by: [email protected] Signed-off-by: Sungjong Seo <[email protected]> Signed-off-by: Namjae Jeon <[email protected]>
Diffstat (limited to 'lib/memory-notifier-error-inject.c')
0 files changed, 0 insertions, 0 deletions