lkml.org 
[lkml]   [1999]   [Jun]   [27]   [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, 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 do suspect that maybe we're not getting the kernel lock somewhere, or
>something like that. That could explain the message you see, because all
>the ext2 block allocation and freeing logic expects to have the kernel
>lock.

I thought about that but I don't think it's a SMP race. In SMP everything
seems fine and I get these messages on an UP machine (with SMP kernel)
with a precise stress-testcase. The error happens always in trunc_indirect
called from trunc_direct (in the middle of unlink(2)). I don't want to
warn too much with this problem though, since it maybe a my local bug I
inserted with my VM changes. (right now I am looking into ext2 though :).

Andrea


-
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.237 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site