Date: Sat, 2 Feb 2002 07:48:05 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Alfred Perlstein <alfred@freebsd.org> Cc: <current@freebsd.org> Subject: Re: lock reversal in fdalloc() Message-ID: <20020202072516.J290-100000@gamplex.bde.org> In-Reply-To: <20020201110130.R18604@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 1 Feb 2002, Alfred Perlstein wrote:
> 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?
Something like that. This was apparently missed when the retry loop was
added. Lite2 has the panic but not the retry loop.
BTW, the retry loop also picks up changes to the limit on descriptors.
In fdalloc(), the corresponding limit is treated as a loop invariant,
but it is not invariant. I think the process's rlimit can't change,
but maxfilesperproc can change even if the process doesn't block, since
it is not protected by FILEDESC_LOCK() :-(. Fortunately, the
maxfilesperproc limit isn't very important.
Bruce
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?20020202072516.J290-100000>