>>> should be easier than making CLONE_PID work properly, which would
>>> require the same sorts of changes plus adding thread IDs and some new
>>> syscalls).
>>
>> Maybe CLONE_PID ought to be your CLONE_MINOR. It would be very good
>> to kill the current CLONE_PID, since /proc can not handle it.
>> Let's think of /proc as having thread ID directories, not process ID
>> directories. The process ID is equal to the thread ID of the manager
>> thread. We just need a way to tell procps that not all threads in /proc
>> are manager threads, perhaps with /proc/$TID/threads files.
>
> This appears easy enough to do. The procfs code just has to omit minor
> threads from the normal process listing, and put them in the directory
> of the leader thread instead.
It is better to avoid that, because it is unnecessarily complicated.
The existing CLONE_PID is simply bad. The concept isn't bad.
Solution: /proc has numeric directories, named by _thread_ ID.
Example: We have process 10, which is a normal process. Like all
processes, it has a manager thread with a TID equal to the PID.
This process becomes multithreaded. We get something like this:
/proc/10 original thread, now the manager. PID==TID
/proc/13 thread 13 (system-wide numer) has PID 10 also
/proc/42 another thread with PID 10
/proc/78 another thread with PID 10
>> I think CLONE_PID doesn't look so impossible if you redefine the
>> contents of /proc as thread directories.
>
> In principle completing CLONE_PID is not much more work than what I'm
> doing. However, for every place where the kernel exposes a pid to
> userspace, somene will need to consider whether a thread equivalent is
> needed and if so write the code. Which sounds like a lot of trouble
> for something we can do perfectly well without.
You planned to fix signal handling, right? With that and the stuff
you already wrote, I'd say you have a working CLONE_PID. The current
CLONE_PID looks like bad news for security and hasn't been useful.
I would suggest that you just recycle the CLONE_PID name and bit.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu