Messages in this thread | | | Date | Tue, 29 Jun 1999 11:33:58 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: [patch] possible ext2 problem in inode_getblk() (2.3.[789]) |
| |
On Sun, 27 Jun 1999, Andrea Arcangeli wrote:
> 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/
| |