linux-kernel - Re: [PATCH] f2fs: avoid potential deadlock in f2fs_sbi

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <8694e965-8da9-29ed-fa3e-c85957194363@huawei.com>
Date:   Mon, 16 Jul 2018 15:18:37 +0800
From:   Chao Yu <yuchao0@...wei.com>
To:     Jaegeuk Kim <jaegeuk@...nel.org>, <linux-kernel@...r.kernel.org>,
        <linux-f2fs-devel@...ts.sourceforge.net>
Subject: Re: [PATCH] f2fs: avoid potential deadlock in f2fs_sbi_store

On 2018/7/15 9:10, Jaegeuk Kim wrote:
> [  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);
> 
> Signed-off-by: Jaegeuk Kim <jaegeuk@...nel.org>

Reviewed-by: Chao Yu <yuchao0@...wei.com>

Thanks,