From owner-freebsd-hackers Wed Apr 9 14:47:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA20145 for hackers-outgoing; Wed, 9 Apr 1997 14:47:15 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA20138 for ; Wed, 9 Apr 1997 14:47:10 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA07549; Wed, 9 Apr 1997 14:27:18 -0700 From: Terry Lambert Message-Id: <199704092127.OAA07549@phaeton.artisoft.com> Subject: Re: Some insight on "dup alloc" problems..... To: dg@root.com Date: Wed, 9 Apr 1997 14:27:17 -0700 (MST) Cc: terry@lambert.org, ponds!rivers@dg-rtp.dg.com, hackers@freebsd.org In-Reply-To: <199704092135.OAA22510@root.com> from "David Greenman" at Apr 9, 97 02:35:09 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > ... > >| vp = (struct vnode *) malloc((u_long) sizeof *vp, > >| M_VNODE, M_WAITOK); > > ************************************************* > > There are mutex locks in the callers of getnewvnode (specifically UFS) > which force the calls to it to be single-threaded, preventing the vnode > allocation race condition you are refering to. I know because I added them > over a year ago: > > revision 1.24 > date: 1995/07/21 03:52:40; author: davidg; state: Exp; lines: +34 -4 > Implement a lock in ffs_vget to prevent a race condition where two processes > try allocate the same inode/vnode, causing a duplicate. Hmm... If so, the locks wouldn't help -- but they wouldn't hurt, either. The real idea was to prevent allocate and delete operations from being interleaved, not to really fix the problem: just work around it. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.