Messages in this thread Patch in this message | | | Date | Wed, 1 Sep 1999 16:41:49 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | [patch] flushpage SMP race with ll_rw_block/bdflush |
| |
After we wait_on_buffer() inside flushpage, if the bh is dirty, bdflush can still start I/O over the buffer that is going to be invalidated.
Suppose this scenario:
CPU0 CPU1 ---- ---- flushpage wait_on_buffer "not locked so return immediatly" bdflush notice the buffer dirty and start ll_rw_block over it mark_buffer_clean refile_the_buffer (bdflush released the lru_lock before starting the I/O) ... clear_bit(Mapped ....) make_request() buffer not mapped -> BUG()
I think moving wait_on_buffer() after mark_clean_buffer() will make sure that we'll look if the buffer is locked only once we'll be sure that nobody can start I/O on the buffer anymore.
This because make_request will giveup when it will notice that the buffer is clean. So even if we'll check the locked bit too early then ll_rw_block will do nothing once the buffer is marked clean.
We must be still very careful to not remove the Mapped bit though, otherwise make_request may still BUG().
this patch against 2.3.16 should fix the SMP race:
--- 2.3.16-flushpage/fs/buffer.c.~1~ Wed Sep 1 09:30:03 1999 +++ 2.3.16-flushpage/fs/buffer.c Wed Sep 1 16:21:54 1999 @@ -1231,16 +1231,10 @@ */ if (offset <= curr_off) { if (buffer_mapped(bh)) { - atomic_inc(&bh->b_count); - wait_on_buffer(bh); if (bh->b_dev == B_FREE) BUG(); mark_buffer_clean(bh); - clear_bit(BH_Uptodate, &bh->b_state); - clear_bit(BH_Mapped, &bh->b_state); - clear_bit(BH_Req, &bh->b_state); - bh->b_blocknr = 0; - atomic_dec(&bh->b_count); + wait_on_buffer(bh); } } curr_off = next_off; I removed also the atomic_dec/inc since they are useless.
Andrea
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |