summaryrefslogtreecommitdiffstats
path: root/kernel
diff options
context:
space:
mode:
authorDave Chinner <david@fromorbit.com>2016-05-19 00:17:26 +1000
committerAl Viro <viro@zeniv.linux.org.uk>2016-05-18 13:20:21 -0400
commit9f5418010940236b2c39ea53b99055ca26ff1279 (patch)
tree5ef0501c5431567c3c47eb6f2ea1bbfd1311390b /kernel
parentfe742fd4f90fa53cf31296bc5131ae1cdd6d84bb (diff)
downloadop-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 'kernel')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud