>BTW. neither getblk nor mark_buffer_uptodate check for i/o completion.
That was exactly what I wanted to point out :).
>Isn't it race? Many filesystem do it this way.
All depends on the semantics you want I think. It doesn't seems black and
white to me.
Note that for example in 2.3.25 with shared mappings you can't avoid
userspace to not change the mapped memory while at the same time a
peripheral is reading it in DMA. This is by design.
But the shared mapped region is only data, while if the buffer you are
over-writing is _valid_ metadata (likely to be metadata otherwise you
wouldn't play with the buffer cache in first place) then you probably like
to know that if your machine will reboot -f, there will be at least an old
_valid_ snapshot of metadata in such block.
So maybe you want a wait_on_buffer() before the memcpy if the buffer you
are going to write to was previously valid.
In my first email of this thread I only answered to the questions I didn't
looked to the code closely (infact I have not quoted the code at all).
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/