> On Sun, 27 Jun 1999, Linus Torvalds wrote:
>
> > - but nobody can see the block before we save the information in the
> > indirect tree.
>
> The race is not that somebody may see the buffer before we have made it
> ready. The problem is that somebody may have just mapped another block
> before us (the patch is somehow confusing but I joined the two sleep, one
> for getblk, the other for mark_buffer_dirty). So after we slept we must
> check if somebody just mapped another block before us. If somebody just
> mapped another block we must bforget our block and return at the top of
> the function trying again with the slot uptodate (otherwise we may
> overwrite the other block).
i too think that this is a real race. The page-lock does not protect
indirect blocks from getting allocated - as they have a much larger
'allocation scope' than direct blocks. Thus two writes might validly
allocate the very same indirect block and write it back into the
one-level-higher indirect block.
the effect of this bug can only be data corruption and lost filesystem
space, but not the 'clear bit' bug Andrea sees - if one of the
mark_buffer_dirty() calls sleeps for a long time and writes back the
indirect pointer later then we end up 'truncating' away all previous (and
pending) writes done on that range of indirection. This bug is a direct
consequence of the i_sem change for writes.
Ingo
-
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/