lkml.org 
[lkml]   [2002]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    Subject[PATCH 2.5.30+] Fourth attempt at a shared credentials patch
    From
    >>>>> " " == 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/

    \
     
     \ /
      Last update: 2005-03-22 13:27    [W:0.030 / U:89.076 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site