Date: Tue, 8 Apr 1997 20:59:07 -0400 (EDT) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> 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..... Message-ID: <199704090059.UAA07429@lakes.water.net>
next in thread | raw e-mail | index | archive | help
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 -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704090059.UAA07429>