Messages in this thread | | | Date | Fri, 9 Aug 2002 21:51:56 +0200 | Subject | [PATCH 2.5.30+] Fourth attempt at a shared credentials patch | From | Trond Myklebust <> |
| |
>>>>> " " == 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |