summaryrefslogtreecommitdiff
path: root/drivers/nfc
diff options
context:
space:
mode:
authorJan Kara <jack@suse.cz>2011-11-26 03:35:39 +0400
committerJan Kara <jack@suse.cz>2012-01-11 16:36:57 +0400
commit353b67d8ced4dc53281c88150ad295e24bc4b4c5 (patch)
treea339a47a9899d01108c6167ffbbefcea07f63912 /drivers/nfc
parente4e11180dfa545233e5145919b75b7fac88638df (diff)
downloadlinux-353b67d8ced4dc53281c88150ad295e24bc4b4c5.tar.xz
jbd: Issue cache flush after checkpointing
When we reach cleanup_journal_tail(), there is no guarantee that checkpointed buffers are on a stable storage - especially if buffers were written out by log_do_checkpoint(), they are likely to be only in disk's caches. Thus when we update journal superblock, effectively removing old transaction from journal, this write of superblock can get to stable storage before those checkpointed buffers which can result in filesystem corruption after a crash. A similar problem can happen if we replay the journal and wipe it before flushing disk's caches. Thus we must unconditionally issue a cache flush before we update journal superblock in these cases. The fix is slightly complicated by the fact that we have to get log tail before we issue cache flush but we can store it in the journal superblock only after the cache flush. Otherwise we risk races where new tail is written before appropriate cache flush is finished. I managed to reproduce the corruption using somewhat tweaked Chris Mason's barrier-test scheduler. Also this should fix occasional reports of 'Bit already freed' filesystem errors which are totally unreproducible but inspection of several fs images I've gathered over time points to a problem like this. CC: stable@kernel.org Signed-off-by: Jan Kara <jack@suse.cz>
Diffstat (limited to 'drivers/nfc')
0 files changed, 0 insertions, 0 deletions