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

    Linus Torvalds wrote:
    > 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.

    Erm... Even if it's you who suggested it? To quote:

    | Also, if it's shared on CLONE_THREAD, then logically the structure already
    | exists: it is "tsk->signal". The _naming_ may be historical and slightly
    | confusing, but the fact is, that's the structure that gets shared on
    | CLONE_THREAD, and there's no technical point to creating a new one.
    | If the name really bothers you, I'd be more willing to rename
    | "tsk->signal", although the pain of that makes me strongly suspect it's
    | not worth it.

    Well, I've come up with a patch to do the renaming; whilst it is quite
    invasive, if it's applied as soon as possible after 2.6.11 is out, it
    shouldn't cause too much of a problem. I can even make the changes in stages
    to have less impact on the drivers.

    Also, _why_ can't signal_struct be changed into something associated with a
    thread group? So it contains the controls for thread-group-wide signalling?
    But that's okay - the struct would then be for thread-group-wide concepts, and
    so it would still fit.

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

    Because I want to have the session- and process-keyrings associated with each
    process to be shared amongst all the threads that process contains, such that
    if one thread joins a new session this affects all its sibling threads
    too. And in this context, I think 'threads' have to be defined by
    CLONE_THREAD. Why else have such a clone flag? Or does CLONE_THREAD not
    "distinguish" threads and processes as far as /proc, exec and exit are

    There's a per-thread keyring available too; and that is strictly 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.

    Just like uids, gids and group lists, eh? I think keys are more comparable to
    those than to permissions masks.

    Besides, from a logical standpoint, I generally think of a "process" as being
    the concept to which threads, fds, VMs, etc can be attached. Obviously Linux
    is more flexible than that, but I nonetheless find it easier to explain the
    semantics to people in terms of processes and threads.

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

    Then redefine the signal_struct structure. There's no particular reason it
    can't be made into the "anchor" block for a thread group, and I can see a
    number of advantages from doing so.

    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 14:10    [W:0.022 / U:2.660 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site