mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-24 09:56:11 +07:00
4ea7772f82
Lockdep is complaining about UDF: ============================================= [ INFO: possible recursive locking detected ] 3.12.0+ #16 Not tainted --------------------------------------------- ln/7386 is trying to acquire lock: (&ei->i_data_sem){+.+...}, at: [<ffffffff8142f06d>] udf_get_block+0x8d/0x130 but task is already holding lock: (&ei->i_data_sem){+.+...}, at: [<ffffffff81431a8d>] udf_symlink+0x8d/0x690 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&ei->i_data_sem); lock(&ei->i_data_sem); *** DEADLOCK *** This is because we hold i_data_sem of the symlink inode while calling udf_add_entry() for the directory. I don't think this can ever lead to deadlocks since we never hold i_data_sem for two inodes in any other place. The fix is simple - move unlock of i_data_sem for symlink inode up. We don't need it for anything when linking symlink inode to directory. Reported-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: Jan Kara <jack@suse.cz> |
||
---|---|---|
.. | ||
balloc.c | ||
dir.c | ||
directory.c | ||
ecma_167.h | ||
file.c | ||
ialloc.c | ||
inode.c | ||
Kconfig | ||
lowlevel.c | ||
Makefile | ||
misc.c | ||
namei.c | ||
osta_udf.h | ||
partition.c | ||
super.c | ||
symlink.c | ||
truncate.c | ||
udf_i.h | ||
udf_sb.h | ||
udfdecl.h | ||
udfend.h | ||
udftime.c | ||
unicode.c |