summaryrefslogtreecommitdiffstats
path: root/drivers/rtc/rtc-tx4939.c
diff options
context:
space:
mode:
authorDave Chinner2013-08-27 00:10:53 +0200
committerBen Myers2013-08-29 17:37:06 +0200
commit84a5b7300c724f4000f689c410aeae3242b4f034 (patch)
tree9982c376b488c62d75ff832e27ca1da69e55a86b /drivers/rtc/rtc-tx4939.c
parentxfs: check for underflow in xfs_iformat_fork() (diff)
downloadkernel-qcow2-linux-84a5b7300c724f4000f689c410aeae3242b4f034.tar.gz
kernel-qcow2-linux-84a5b7300c724f4000f689c410aeae3242b4f034.tar.xz
kernel-qcow2-linux-84a5b7300c724f4000f689c410aeae3242b4f034.zip
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 'drivers/rtc/rtc-tx4939.c')
0 files changed, 0 insertions, 0 deletions