From owner-freebsd-current Thu Jul 18 11:40: 9 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 8292E37B400; Thu, 18 Jul 2002 11:40:02 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38F9443E6A; Thu, 18 Jul 2002 11:40:02 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g6IIe2CV019270; Thu, 18 Jul 2002 11:40:02 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g6IIe25G019269; Thu, 18 Jul 2002 11:40:02 -0700 (PDT) (envelope-from dillon) Date: Thu, 18 Jul 2002 11:40:02 -0700 (PDT) From: Matthew Dillon Message-Id: <200207181840.g6IIe25G019269@apollo.backplane.com> To: John Baldwin Cc: current@FreeBSD.ORG Subject: Re: Questions about kern_descrip.c References: 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 : :In revision 1.94 of kern_descrip.c, in the dup2() syscall a goto :retry loop was added so that if we did a fdalloc() we always retested :everything. Since fd_nfiles can't shrink and new and old can't :change, I don't see why the loop is necessary. Neither dup() or :the F_DUPFD fcntl() were modified in this way either. Also, :calling fdalloc() in this case is somewhat bogus, because fdalloc() :is going to try and reserve an open slot and update variables such :as fd_lastfile, etc. appropriately. Perhaps we should have an :fdextend() function that both dup2() and fdalloc() call? Also, :in do_dup() you have commented out the call to munmapfd() on an :open file with UF_MAPPED and never turned it back on. Was that :intentional or just an accidental oversight? : :-- : :John Baldwin <>< http://www.FreeBSD.org/~jhb/ 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. the munmap descriptor junk is obsolete and has not been used for a very long time. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message