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

[Trond Myklebust <trond.myklebust@fys.uio.no>]

>>>>> " " == Dave McCracken <dmccr@us.ibm.com> writes:

     > --On Thursday, August 08, 2002 11:55:05 PM +0200 Trond
     > Myklebust <trond.myklebust@fys.uio.no> wrote:

    >> What if one thread is doing an RPC call while the other is
    >> changing the 'groups' entry?

     > Gah.  Good point.  Ok, I've added locking to the cred structure
     > to handle this.  Here's my new patch with those changes made:

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

     > I've gone through all the code again, and don't see any other
     > places where locking is really necessary.  Feel free to point
     > them out to me if you see any.

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.

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).

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...

Cheers,
  Trond