diff options
author | Dave Chinner <dchinner@redhat.com> | 2013-08-27 02:10:53 +0400 |
---|---|---|
committer | Ben Myers <bpm@sgi.com> | 2013-08-29 19:37:06 +0400 |
commit | 84a5b7300c724f4000f689c410aeae3242b4f034 (patch) | |
tree | 9982c376b488c62d75ff832e27ca1da69e55a86b /fs/xfs/xfs_dir2.h | |
parent | 0d0ab120d1fe90fcc73a2bfff3945bea636b3025 (diff) | |
download | linux-84a5b7300c724f4000f689c410aeae3242b4f034.tar.xz |
xfs: don't account buffer cancellation during log recovery readahead
When doing readhaead in log recovery, we check to see if buffers are
cancelled before doing readahead. If we find a cancelled buffer,
however, we always decrement the reference count we have on it, and
that means that readahead is causing a double decrement of the
cancelled buffer reference count.
This results in log recovery *replaying cancelled buffers* as the
actual recovery pass does not find the cancelled buffer entry in the
commit phase of the second pass across a transaction. On debug
kernels, this results in an ASSERT failure like so:
XFS: Assertion failed: !(flags & XFS_BLF_CANCEL), file: fs/xfs/xfs_log_recover.c, line: 1815
xfstests generic/311 reproduces this ASSERT failure with 100%
reproducability.
Fix it by making readahead only peek at the buffer cancelled state
rather than the full accounting that xlog_check_buffer_cancelled()
does.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Diffstat (limited to 'fs/xfs/xfs_dir2.h')
0 files changed, 0 insertions, 0 deletions