Messages in this thread | | | Date | Fri, 5 Nov 1999 17:33:50 +0100 (CET) | From | Mikulas Patocka <> | Subject | Race 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/
| |