Date: Sun, 27 Sep 1998 02:39:33 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Bruce Evans <bde@zeta.org.au>, Don.Lewis@tsc.tdk.com, freebsd-current@FreeBSD.ORG, street@iname.com Subject: Re: Softupdates panics Message-ID: <199809270939.CAA01920@salsa.gv.tsc.tdk.com> In-Reply-To: Bruce Evans <bde@zeta.org.au> "Re: Softupdates panics" (Sep 27, 7:54am)
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 27, 7:54am, Bruce Evans wrote: } Subject: Re: Softupdates panics } I believe there are races in xxx_checkpath(). It certainly unlocks, } and I've been able to damage the directory structure by simulating a } race: arrange for ufs_checkpath() to sleep for a minute or two near } the end of the main loop in ufs_checkpath(), and while it is sleeping, } manually rearrange the unlocked directory tree in a certain way. I could believe that changing the hierarchy could bypass the check that ufs_checkpath() just did, which would orphan part of the directory tree, just like the comment says. Just rearranging stuff in the directory should be ok because of the following call to relookup(), which locks the directory and repeats the search to find the proper offset. Also this panic has been reported by enough people to make me think that this problem is a more subtle race, but one that is triggered by more common operations. That said, I haven't managed to trigger it here. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809270939.CAA01920>