From owner-freebsd-hackers Sat Jun 10 13: 0:31 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by hub.freebsd.org (Postfix) with ESMTP id 3F68237C72B; Sat, 10 Jun 2000 13:00:26 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 130rQe-0000HA-0K; Sat, 10 Jun 2000 20:00:24 +0000 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id VAA16242; Sat, 10 Jun 2000 21:01:35 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sat, 10 Jun 2000 21:05:24 +0100 (BST) From: Doug Rabson To: Alfred Perlstein Cc: Brian Fundakowski Feldman , hackers@freebsd.org Subject: Re: uidinfo has many race conditions. In-Reply-To: <20000610110326.R18462@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 Sat, 10 Jun 2000, Alfred Perlstein wrote: > * Brian Fundakowski Feldman [000610 09:13] wrote: > > 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. > > Well if we get an atomic_t it could be done that way, even if we > fail the race for updating and go beyond our rlimit slightly it's > much cheaper than a spinlock from my PoV. The only problem is > that afaik on some archs atomic_t can be quite small, we'd have > to watch for overflow, perhaps a spinlock is a better idea however > only if the next thing I mention here is realized: You can use atomic_add_*() to do safe arithmetic on memory locations. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message