lkml.org 
[lkml]   [1999]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

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