On Thu, Nov 23, 2000 at 08:26:42PM -0500, Roland McGrath wrote:
> It looks to me like the ext2fs block allocation code (getblk.c) can set
> dn_set_mtime when called from the pager whiled not holding the node lock.
> It will hold node->dn->alloc_lock, but that is all.
I think what you say is correct, especially as my other info (which I sent
before reading this mail) seems to be 100% in agreement with this analysis.
> The ext2_getblk code is called sometimes with the node lock held
> (storeinfo.c, diskfs_grow) and sometimes without (pager). So it cannot
> just take the lock around setting dn_set_?time. I'm not sure whether the
> node lock really ought to be held around setting them or not.
Looking at write_one_disknode in inode.c, I'm not even sure if holding the
lock would be enough. The stack trace shows that the lock was held during
the assertion failure. I don't see how you can sync the node without locking
it, and expect that nobody changes the dn_set_?times in the meantime. Maybe
the assertion is bogus? Even between calling diskfs_set_node_times and the
assertion is a small time window (which seems to be too small to show up in
any normal situation) where someone can stomp on the time flags while
holding the lock or not.
> From reading
> the ufs code, I cna't tell whether it has the same bug, but I think it does.
Yes, but it has a smaller window between diskfs_set_node_times and
write_node.
write_all_disknodes ()
{
error_t
helper (struct node *np)
{
diskfs_set_node_times (np);
write_node (np);
return 0;
}
diskfs_node_iterate (helper);
}
My preliminary and by no means authoritative impression is that the
assertion cannot be guaranteed without holding locks on either side (sync
thread and everyone else).
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
