Messages in this thread | | | Date | Sun, 27 Jun 1999 20:12:16 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: [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/
| |