On Sat, 10 Jun 2000, Alfred Perlstein wrote:
> * Brian Fundakowski Feldman <[EMAIL PROTECTED]> [000610 09:13] wrote:
> > On Fri, 9 Jun 2000, Alfred Perlstein wrote:
> >
> > > * Alfred Perlstein <[EMAIL PROTECTED]> [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: [EMAIL PROTECTED]
Nonlinear Systems Ltd. Phone: +44 20 8442 9037
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
