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:
> >> 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.
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 tells you that the _tasks_ are threads of a single process.
> They are non-POSIX threads.
Nor are they threads by any conventional sense of the definition.
> >> 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!
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. Maybe this is what you mean
by XID.
> >> 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.
--Chris
-
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