From owner-freebsd-current Thu Jul 18 13:19:29 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8427137B400 for ; Thu, 18 Jul 2002 13:19:26 -0700 (PDT) Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A7AB43E58 for ; Thu, 18 Jul 2002 13:19:26 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 3139 invoked from network); 18 Jul 2002 20:19:21 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 Jul 2002 20:19:21 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g6IKJJ062730; Thu, 18 Jul 2002 16:19:19 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200207181908.g6IJ8H5k019431@apollo.backplane.com> Date: Thu, 18 Jul 2002 16:19:25 -0400 (EDT) From: John Baldwin To: Matthew Dillon Subject: Re: Questions about kern_descrip.c Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 18-Jul-2002 Matthew Dillon wrote: > >:> 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 <>< 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. But it doesn't really matter if we cycle the lock. What I described is the current behavior, btw. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message