Christopher Smith writes:
> On Thu, Mar 30, 2000 at 04:13:24AM -0500, Albert D. Cahalan wrote:
>> I don't think "unique VM's" is right for Linux. Tasks that share
>> files are related just as much as those that share memory.
>
> If you are referring to sharing file handles, then I have to disagree
> quite strongly with you here. Every UNIX implementation as well as the
> POSIX standard makers would also have to disagree. There's a reason
> why a unix pid refers to a unique VM.
Huh??? No other UNIX does CLONE_FILES like Linux does.
This is way outside the scope of POSIX.
If I call clone() with this:
CLONE_FS | CLONE_FILES | CLONE_SIGHAND
do I not have a form of threading? These tasks are certainly not
independent processes.
>> Would you accept a patch that exposed identifiers for every
>> shareable part of a task? (kernel pointer values would work)
>> Example: a group of 8 related tasks might have 5 address
>> spaces total, which "ps" must use to determine total memory.
>
> That sounds kind of neat, but it seems like it would impose a lot of
> overhead, and I'm not sure what the benefit is. If two processes are
> the result of a fork sharing file handles, what does that really tell
> me about them?
It tells you that the _tasks_ are threads of a single process.
They are non-POSIX threads.
>> Would you accept a patch that, for any group of related tasks,
>> prevented reuse of the initial PID by an unrelated task?
>> While a well-behaved thread package would not let the initial
>> task exit early, an evil thread package may well seek to
>> confuse the system administrator.
>
> IMHO the kernel should be assigning thread-id's which are unique
> within their pid. A sys-admin would normally doesn't try to isolate
> specific threads anyway, it's enough to know, "one of the threads in
> this process is sucking up all the CPU cycles it can take". Process
> level information is all you need to know.
Yes, and that process-level information gets messed up when the
initial task ID get reused.
1. evil-proc (PID 304) creates 666 threads
2. evil-proc's leader does an exit(), leaving the threads
3. root logs in, and his shell gets PID 304
Does root's shell have 667 threads? Does init have 667 threads?
Gee, init must have gone insane... time to reboot!
>> Would you accept a patch that allowed kill-by-XID, so that the
>> PID wrap-around race condition would be eliminated? This could
>> be unrelated to the above, or it could be just a different scope.
>
> This seems like solving the problem backwards. If you want to avoid
> the PID wrap-around problem, why not make PID wider rather than
> introducing an entirely new field which happens to be wider?
I don't think a 64-bit PID is sane. 32 bits are not enough.
Also this would destroy compatibility.
$ ps
149273892759283528 pts/1 00:00:00 bash
1295472835929183911 pts/1 00:00:00 ps
829423828282352525 pts/1 00:00:00 a.out
$ kill 829423828282352525
$
Doesn't that look awful to you? The "ps" command needs a 64-bit
or larger value for reliability, but it makes an awful PID.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:27 EST