From owner-freebsd-hackers Sat Jun 10 9: 9:29 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 23A6837B812; Sat, 10 Jun 2000 09:09:21 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Sat, 10 Jun 2000 12:09:18 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Alfred Perlstein Cc: hackers@FreeBSD.ORG Subject: Re: uidinfo has many race conditions. In-Reply-To: <20000609170758.O18462@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 9 Jun 2000, Alfred Perlstein wrote: > * Alfred Perlstein [000609 16:45] wrote: > > hi, > > > > Is it just me or does the fact that uidinfo structures (see > > kern/kern_proc.c) are allocated with M_WAITOK after finding them > > fails and then inserted into the uidhash structure a race condition? > > > > Index: kern_proc.c > > =================================================================== > > Yes, I know i forgot to put the created ones back into the list, I was > just a bit flusteres after reading over the code. I'll have some more > later. With regard to sbsize itself, the test-and-branch conditions do not have to be atomic. It really isn't that important. The incrementing does, though, and to fix that a very lightweight mutex should be used. How about a simplelock? That should work perfectly. As for uidinfo itself, I feel it should be done with a mutex over uihashtbl. It should be grabbed if the hash for the uid is not found, tested again (to see if we lost the race), and allocated. I can't see a way to poke holes in that, and it would be quite efficient. > -Alfred -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message