Date: Fri, 1 Feb 2002 11:01:30 -0800 From: Alfred Perlstein <alfred@freebsd.org> To: Bruce Evans <bde@zeta.org.au> Cc: current@freebsd.org Subject: Re: lock reversal in fdalloc() Message-ID: <20020201110130.R18604@elvis.mu.org> In-Reply-To: <20020131104831.E18604@elvis.mu.org>; from alfred@freebsd.org on Thu, Jan 31, 2002 at 10:48:32AM -0800 References: <20020201043751.O5590-100000@gamplex.bde.org> <20020131104831.E18604@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Alfred Perlstein <alfred@freebsd.org> [020131 10:48] wrote:
> * Bruce Evans <bde@zeta.org.au> [020131 09:42] wrote:
> >
> > I'm not sure that releasing the lock here is safe, but other parts of
> > fdalloc() do this.
>
> I don't think this is safe at a glance, I think it's only safe right
> before return'ing from the function. I'll look at it later tonight.
It's actually safe... however.... dup2 thinks that we won't race
for the file slot:
if (new >= fdp->fd_nfiles) {
if ((error = fdalloc(td, new, &i))) {
FILEDESC_UNLOCK(fdp);
return (error);
}
if (new != i)
panic("dup2: fdalloc");
/*
* fdalloc() may block, retest everything.
*/
goto retry;
}
basically it seems to get pissy if it doesn't get the file slot it asks
for, so if another thread wins the race here, we'll panic. this problem
seems to also exist for 4.x and previous versions of freebsd.
I'd like to get this fixed. Any suggestions? I think simply
removing the assertion should remove this hazzard, correct?
--
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/
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?20020201110130.R18604>