mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-11-05 10:13:25 -05:00
| Filename | Latest commit message | Latest commit date |
|---|---|---|
9b57988db9
When running several fsx's and other filesystem stress tests, we found cases where an unmapped buffer was still being sent to submit_bh by the ext3 dirty data journaling code. I saw this happen in two ways, both related to another thread doing a truncate which would unmap the buffer in question. Either we would get into journal_dirty_data with a bh which was already unmapped (although journal_dirty_data_fn had checked for this earlier, the state was not locked at that point), or it would get unmapped in the middle of journal_dirty_data when we dropped locks to call sync_dirty_buffer. By re-checking for mapped state after we've acquired the bh state lock, we should avoid these races. If we find a buffer which is no longer mapped, we essentially ignore it, because journal_unmap_buffer has already decided that this buffer can go away. I've also added tracepoints in these two cases, and made a couple other tracepoint changes that I found useful in debugging this. Signed-off-by: Eric Sandeen <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> |
||
| .. | ||
| checkpoint.c | ||
| commit.c | ||
| journal.c | ||
| Makefile | ||
| recovery.c | ||
| revoke.c | ||
| transaction.c | ||