From owner-freebsd-hackers  Tue Apr  8 21:50:45 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id VAA25406
          for hackers-outgoing; Tue, 8 Apr 1997 21:50:45 -0700 (PDT)
Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id VAA25401
          for <freebsd-hackers@freefall.FreeBSD.org>; Tue, 8 Apr 1997 21:50:41 -0700 (PDT)
Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02)
	id AA25253; Wed, 9 Apr 1997 00:50:06 -0400
Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Wed,  9 Apr 1997 00:50 EDT
Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id UAA19324; Tue, 8 Apr 1997 20:52:56 -0400 (EDT)
Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id UAA07429; Tue, 8 Apr 1997 20:59:07 -0400 (EDT)
Date: Tue, 8 Apr 1997 20:59:07 -0400 (EDT)
From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
Message-Id: <199704090059.UAA07429@lakes.water.net>
To: ponds!root.com!dg, ponds!freefall.cdrom.com!freebsd-hackers,
        ponds!lakes.water.net!rivers, ponds!lambert.org!terry
Subject: Re: Some insight on "dup alloc" problems.....
Content-Type: text
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Terry writes:
> 
> >  Here's today's installment :-)
> > 
> >  See what you think about this.
> 
> [ ... ]
> 
> > Does anyone have any other potential functions to check into (that is,
> > what could be run in my small region that could cause the problem.)
> > [I note that aha_intr() isn't in the list above - I assumed that since
> > we were at splbio(); I wouldn't need to check on that.]
> 
> Establish a lock in getnewvnode() to prevent it from being reentered.
> 
> Really.
> 
> Sleep on the addrss of the proc struct or something equally process
> specific.
> 
> Use a while loop and reacquire after wakeup to make sure that you aren't
> one of several waiters (the one who didn't get the lock).
> 
> If you have to sleep in kmem_malloc() or the vm system, you'll notice
> that all processes will sleep on the same addresses, with no guard against
> thundering herd causing them to acquire the same memory.

 I have it on good authority that there is a mutex lock there to
prevent this problem... can you point me to the 2.1.7 source you're
talking about (with say, some arrows labeling "<<< right here", no
need to be less than obvious...)  and we can verify that.

 Ummm... besides; the location I'm dealing with doesn't sleep,
it could only be interrupted by something higher than splbio().
[like a hardclock, for instance, which I'm not even sure FreeBSD
has - I haven't read that source yet.]

	- Dave Rivers -