Re: [PATCH 2.5.30+] Fourth attempt at a shared credentials patch

[Dave McCracken <dmccr@us.ibm.com>]

--On Friday, August 09, 2002 09:51:56 PM +0200 Trond Myklebust
<trond.myklebust@fys.uio.no> wrote:

> Err... Well my original point about your changes to the sunrpc code
> still stand: no spinlocking there AFAICS. In addition, you'll want to
> talk to the Intermezzo people: they do allocation of buffers based on
> the (volatile) value of cred->ngroups.

Oops.  I missed the sunrpc case.  This patch fixes it:

http://www.ibm.com/linux/ltc/patches/misc/cred-2.5.30-6.diff.gz

I think I mostly nailed the intermezzo case.  I did go through it.

> Finally, you also want all those reads and changes to more than one
> value in the credential such as the stuff in security/capability.c, or
> net/socket.c,... to be atomic. (Note: This is where 'struct ucred'
> with COW gives you an efficiency gain).

I disagree.  It won't generate bogus values of any of these fields.  There
may be some cases where it'll pick up a combination of before and after
values, but I don't see where any of that is fatal.
 
> Please also note that you only need spinlocking for the particular
> case of tasks that have set CLONE_CRED. In all other cases, it adds a
> rather nasty overhead...

Spinlock isn't nasty overhead, if it's not contested. It seems to me that
checking whether it's shared is as much overhead as just taking the lock.

Dave McCracken

======================================================================
Dave McCracken          IBM Linux Base Kernel Team      1-512-838-3059
dmccr@us.ibm.com                                        T/L   678-3059