diff options
author | Jan Kara <jack@suse.cz> | 2013-12-23 22:02:16 +0100 |
---|---|---|
committer | Jan Kara <jack@suse.cz> | 2013-12-23 22:02:16 +0100 |
commit | 4ea7772f828a2f1cf6fbf96a3e6f99ae149d2724 (patch) | |
tree | 2515839eb42739317490f2365ea303435ea236f3 /Documentation | |
parent | 301d4c9a286bc7dc4fb3cda21131be91a582fa79 (diff) |
udf: Fix lockdep warning from udf_symlink()
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>
Diffstat (limited to 'Documentation')
0 files changed, 0 insertions, 0 deletions