[lkml]   [2005]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Properly share process and session keyrings with CLONE_THREAD

    On Fri, 25 Feb 2005, David Howells wrote:
    > The attached patch causes process and session keyrings to be shared properly
    > when CLONE_THREAD is in force. It does this by moving the keyring pointers
    > into struct signal_struct[*].

    I do not see the point of associating keys with signal state.

    And it _is_ signal state, even if some people mistakenly think that it's
    about "processes". Linux still hasn't fallen into the trap of believing
    that POSIX threads are somehow magical and the only way to do things.

    The kernel very much believes in various shared resources. Signal state
    (tty, resource limits, and actual signals handlers) is one such shared
    thing, but so is VM state, file table state etc etc. Why would keys
    logically be associated with signals, and not with the file table, for
    example? Or the VM? Or just per-thread?

    In other words, what does this buy us, if anything? From a logical
    standpoint, I'd have said that it makes more sense to associate this with
    the filesystem information, since keys would tend to mostly go together
    with the notion of permissions on file descriptors.

    Making keys be associated with signals just doesn't seem to make any

    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: 2009-11-18 23:46    [W:0.020 / U:0.312 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site