Date: Thu, 18 Jul 2002 12:08:17 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Baldwin <jhb@FreeBSD.ORG> Cc: current@FreeBSD.ORG Subject: Re: Questions about kern_descrip.c Message-ID: <200207181908.g6IJ8H5k019431@apollo.backplane.com> References: <XFMail.20020718145724.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:> The issue with dup2() was a race against open() or close() :> I believe, where dup2() could potentially dup into a :> descriptor that open() was about to use. Unfortunately, it :> does appear that dup() has the same issue. :> :> fdalloc() does not reserve the descriptor number it :> returns, it simply finds a free slot and says 'this :> index is a free slot'. Even in the latest -current, :> fdalloc() releases the fdp lock when it goes to :> MALLOC so the race appears to still be present. : :Well, execpt that if we malloc(), we then grab the lock and loop :again. If we return without an error, it means we reserved a slot :while holding a lock and returned with the lock still held. : :-- : :John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ Yes, that makes sense... and it would be fairly trivial optimization to make. I suppose you could have fdalloc() return EAGAIN or something like that to indicate that it had to cycle the lock. -Matt Matthew Dillon <dillon@backplane.com> 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?200207181908.g6IJ8H5k019431>