From owner-freebsd-hackers Sat Jun 10 18:46:29 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id AAFAC37B683; Sat, 10 Jun 2000 18:46:24 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Sat, 10 Jun 2000 21:46:23 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Doug Rabson Cc: Alfred Perlstein , hackers@freebsd.org Subject: Re: uidinfo has many race conditions. In-Reply-To: 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, Doug Rabson wrote: > > 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. Yeah, but rlim_t isn't small enough to do that on an i386 :( Anyway, I don't think race conditions will ever really happen with the code, since the only interrupts that can modify sbsize are the PF_LOCAL ones, and those are (AFAIK) synchronous. > -- > Doug Rabson Mail: dfr@nlsystems.com > Nonlinear Systems Ltd. Phone: +44 20 8442 9037 -- 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