]> git.ipfire.org Git - thirdparty/xfsprogs-dev.git/commit
repair: don't unlock prefetch tree to read discontig buffers
authorDave Chinner <dchinner@redhat.com>
Fri, 9 May 2014 04:50:12 +0000 (14:50 +1000)
committerDave Chinner <david@fromorbit.com>
Fri, 9 May 2014 04:50:12 +0000 (14:50 +1000)
commitbbd32754acbd3d7368c403e8d386e55ecb8034e7
treed3c7fd1e008ab931eae633e6461904e5b8e08e7a
parent75b480dad5f54d10e77750b2cf8793c04aa5537a
repair: don't unlock prefetch tree to read discontig buffers

The way discontiguous buffers are currently handled in prefetch is
by unlocking the prefetch tree and reading them one at a time in
pf_read_discontig(), inside the normal loop of searching for buffers
to read in a more optimized fashion.

But by unlocking the tree, we allow other threads to come in and
find buffers which we've already stashed locally on our bplist[].
If 2 threads think they own the same set of buffers, they may both
try to delete them from the prefetch btree, and the second one to
arrive will not find it, resulting in:

        fatal error -- prefetch corruption

To fix this, simply abort the buffer gathering loop when we come
across a discontiguous buffer, process the gathered list as per
normal, and then after running the large optimised read, check to
see if the last buffer on the list is a discontiguous buffer.
If is is discontiguous, then issue the discontiguous buffer read
while the locks are not held. We only ever have one discontiguous
buffer per read loop, so it is safe just to check the last buffer in
the list.

The fix is loosely based on a a patch provided by Eric Sandeen, who
did all the hard work of finding the bug and demonstrating how to
fix it.

Reported-by:Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
repair/prefetch.c