lkml.org 
[lkml]   [1999]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRace in buffer code (Was Re: move block #A to block #B on a given device.)
> >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.

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/

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