lkml.org 
[lkml]   [2003]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:32    [W:0.041 / U:8.944 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site