[lkml]   [2002]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[PATCH 2.5.30+] Fourth attempt at a shared credentials patch
>>>>> " " == Dave McCracken <> writes:

> --On Thursday, August 08, 2002 11:55:05 PM +0200 Trond
> Myklebust <> 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:


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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:27    [W:0.064 / U:6.888 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site