> > >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.
>
> What if user does cat /dev/hda1>/dev/null on mounted device while
> filesystem driver does getblk? ... the buffer gets corrupted.
>
> User: Filesystem driver:
> --------------------------------------------------------
> open("/dev/hda1", O_RDONLY);
> read();
> waiting for io completion...
> getblk();
> mark_buffer_uptodate();
> write_some_data_there
> read data is stored, end_request()
> BOOM! changes are lost.
There is another - more severe - destruction case: breada. On filesystems
that use breada it can smash buffers randomly!
Mikulas Patocka
-
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/