From owner-freebsd-current Thu Jul 18 15:35:52 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 EE60137B400 for ; Thu, 18 Jul 2002 15:35:47 -0700 (PDT) Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88F8043E3B for ; Thu, 18 Jul 2002 15:35:47 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 15634 invoked from network); 18 Jul 2002 22:35:46 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail14.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 Jul 2002 22:35:46 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g6IMZj063311; Thu, 18 Jul 2002 18:35:45 -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: <200207182117.g6ILHuFr020395@apollo.backplane.com> Date: Thu, 18 Jul 2002 18:35:55 -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: > >:>:-- >:>: >:>: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/ > > Well, the original code for dup2() looped to ensure that the > source descriptor number was still a valid descriptor. Why > the dup() code doesn't do this I'm not sure, but I think it > needs to. If you cycle the locks and do not retry, someone else > could get in and close() the source descriptor and dup2() will > not return an error when it should. > > Also, do_dup() assumes that the source descriptor is non-NULL. > If dup2() (and dup()) do not retry then do_dup() can wind up > getting called with fd_ofiles[old] NULL (race against another > thread close()ing or dup2()ing over the original descriptor). > > If I remember right, a dup2()/dup2() race was one of the problems > being explicitly solved by this commit. Okies, I'll look at this some more. We might need to move the loop into do_dup(), or have do_dup() do an additional check. -- 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