Messages in this thread | | | Date | Mon, 3 Feb 2003 10:29:38 +0100 (CET) | From | Mikulas Patocka <> | Subject | Re: 2.0, 2.2, 2.4, 2.5: fsync buffer race |
| |
On Sun, 2 Feb 2003, Andrew Morton wrote:
> Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz> wrote: > > > > > void wait_and_rw_block(...) > > > { > > > wait_on_buffer(bh); > > > ll_rw_block(...); > > > } > > > > It would fail if other CPU submits IO with ll_rw_block after > > wait_on_buffer but before ll_rw_block. > > In that case, the caller's data gets written anyway, and the caller will wait > upon the I/O which the other CPU started. So the ll_rw_block() behaviour is > appropriate.
You are partly right, but it suffers from smp memory ordering bug:
CPU 1 write data to buffer (but they are in cpu-local buffer and do not go to the bus)
tests buffer_locked in wait_and_rw_block->wait_on_buffer, sees unlocked
CPU 2 starts to write the buffer, but does not see data written by CPU 1 yet
cpu flushes data to bus calls ll_rw_block, it sees buffer_locked, exits. new data are lost.
There should be smp_mb(); before wait_on_buffer in wait_and_rw_block.
BTW. why don't you just patch ll_rw_block so that it waits if it sees a locked buffer -- you get much cleaner code with only one test for locked buffer.
Mikulas
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |