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/