Christopher Smith writes:
> On Thu, Mar 30, 2000 at 05:32:53PM -0500, Albert D. Cahalan wrote:
>> Christopher Smith writes:
>>> On Thu, Mar 30, 2000 at 04:13:24AM -0500, Albert D. Cahalan wrote:
>> 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.
>
> Ok. I see what you're talking about. No, I would not consider this a
> form of threading. To me, threads share an address space. What you're
> describing is a very bizarre and unique scenario.
It may be bizarre, but "ps" has to deal with it. Linux allows
all sorts of strange things. I do consider these tasks to be
threads of a single process.
>>>> 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.
...
>> 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!
>
> The whole idea is that the process ID would be shared by all
> the threads, and therefore all threads in 'evil-proc' would
> have to die before the process ID would be recaptured.
Yes, and how is this to be done? One could simply make the lead
thread block if it tries to exit before the other threads. OK?
(this could be a new process state -- other systems have it)
> Maybe this is what you mean by XID.
I use the term XID because:
1. "PID" could mean either a POSIX process ID or a Linux task ID.
2. Both the Linux task ID and POSIX process ID are too short.
>>>> 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.
>
> It may look awful, but if you really need more than 32-bits to avoid
> pid reclamation issues so be it. Things like how process ID's are
> displayed should not impact the kernel. Indeed, ps has all kinds of
> options for rectifying this situation should it choose to.
No, we REALLY CAN NOT do this. The C library eats flaming death,
along with just about everything else. The debugger won't work.
You ought to see what "ps j" would look like. It would need 70 more
columns!!! Then of course there are the admins who'd not like to type
19-digit numbers.
-
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:28 EST