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, Andrea Arcangeli wrote:
>
> I think I seen a potential race, here it is a patch against pre4. The
> problem is that mark_buffer_dirty() may sleep in inode_getblk().

I do not think this can be a problem. Let me tell you why:

- we need to clear the new buffer and mark it uptodate and dirty. That's
obvious and ok.
- but nobody can see the block before we save the information in the
indirect tree.

So: we only need to do so before we actually "export" the buffer. Before
that export, the buffer can be considered completely private to that
particular routine, as there is no other routine that could look up the
same buffer. So we need to clear it and mark it dirty before we install it
in the indirect block tree, but that's the only requirement.

And the old code does that. You move the clearing up a bit, but the old
code was fine too. That's why I can't see that your patch could possibly
make any difference.

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.

Linus


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