[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.050 / U:20.084 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site