diff options
author | Dave Chinner <david@fromorbit.com> | 2016-05-19 00:17:26 +1000 |
---|---|---|
committer | Al Viro <viro@zeniv.linux.org.uk> | 2016-05-18 13:20:21 -0400 |
commit | 9f5418010940236b2c39ea53b99055ca26ff1279 (patch) | |
tree | 5ef0501c5431567c3c47eb6f2ea1bbfd1311390b /Makefile | |
parent | fe742fd4f90fa53cf31296bc5131ae1cdd6d84bb (diff) | |
download | op-kernel-dev-9f5418010940236b2c39ea53b99055ca26ff1279.zip op-kernel-dev-9f5418010940236b2c39ea53b99055ca26ff1279.tar.gz |
xfs: concurrent readdir hangs on data buffer locks
There's a three-process deadlock involving shared/exclusive barriers
and inverted lock orders in the directory readdir implementation.
It's a pre-existing problem with lock ordering, exposed by the
VFS parallelisation code.
process 1 process 2 process 3
--------- --------- ---------
readdir
iolock(shared)
get_leaf_dents
iterate entries
ilock(shared)
map, lock and read buffer
iunlock(shared)
process entries in buffer
.....
readdir
iolock(shared)
get_leaf_dents
iterate entries
ilock(shared)
map, lock buffer
<blocks>
finish ->iterate_shared
file_accessed()
->update_time
start transaction
ilock(excl)
<blocks>
.....
finishes processing buffer
get next buffer
ilock(shared)
<blocks>
And that's the deadlock.
Fix this by dropping the current buffer lock in process 1 before
trying to map the next buffer. This means we keep the lock order of
ilock -> buffer lock intact and hence will allow process 3 to make
progress and drop it's ilock(shared) once it is done.
Reported-by: Xiong Zhou <xzhou@redhat.com>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions