Skip to content
  • Jaegeuk Kim's avatar
    f2fs: avoid potential deadlock in f2fs_sbi_store · ee0b97e1
    Jaegeuk Kim authored
    [ Upstream commit a1933c09
    
     ]
    
    [  155.018460] ======================================================
    [  155.021431] WARNING: possible circular locking dependency detected
    [  155.024339] 4.18.0-rc3+ #5 Tainted: G           OE
    [  155.026879] ------------------------------------------------------
    [  155.029783] umount/2901 is trying to acquire lock:
    [  155.032187] 00000000c4282f1f (kn->count#130){++++}, at: kernfs_remove+0x1f/0x30
    [  155.035439]
    [  155.035439] but task is already holding lock:
    [  155.038892] 0000000056e4307b (&type->s_umount_key#41){++++}, at: deactivate_super+0x33/0x50
    [  155.042602]
    [  155.042602] which lock already depends on the new lock.
    [  155.042602]
    [  155.047465]
    [  155.047465] the existing dependency chain (in reverse order) is:
    [  155.051354]
    [  155.051354] -> #1 (&type->s_umount_key#41){++++}:
    [  155.054768]        f2fs_sbi_store+0x61/0x460 [f2fs]
    [  155.057083]        kernfs_fop_write+0x113/0x1a0
    [  155.059277]        __vfs_write+0x36/0x180
    [  155.061250]        vfs_write+0xbe/0x1b0
    [  155.063179]        ksys_write+0x55/0xc0
    [  155.065068]        do_syscall_64+0x60/0x1b0
    [  155.067071]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
    [  155.069529]
    [  155.069529] -> #0 (kn->count#130){++++}:
    [  155.072421]        __kernfs_remove+0x26f/0x2e0
    [  155.074452]        kernfs_remove+0x1f/0x30
    [  155.076342]        kobject_del.part.5+0xe/0x40
    [  155.078354]        f2fs_put_super+0x12d/0x290 [f2fs]
    [  155.080500]        generic_shutdown_super+0x6c/0x110
    [  155.082655]        kill_block_super+0x21/0x50
    [  155.084634]        kill_f2fs_super+0x9c/0xc0 [f2fs]
    [  155.086726]        deactivate_locked_super+0x3f/0x70
    [  155.088826]        cleanup_mnt+0x3b/0x70
    [  155.090584]        task_work_run+0x93/0xc0
    [  155.092367]        exit_to_usermode_loop+0xf0/0x100
    [  155.094466]        do_syscall_64+0x162/0x1b0
    [  155.096312]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
    [  155.098603]
    [  155.098603] other info that might help us debug this:
    [  155.098603]
    [  155.102418]  Possible unsafe locking scenario:
    [  155.102418]
    [  155.105134]        CPU0                    CPU1
    [  155.107037]        ----                    ----
    [  155.108910]   lock(&type->s_umount_key#41);
    [  155.110674]                                lock(kn->count#130);
    [  155.113010]                                lock(&type->s_umount_key#41);
    [  155.115608]   lock(kn->count#130);
    
    Reviewed-by: default avatarChao Yu <yuchao0@huawei.com>
    Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    ee0b97e1