This is as good a time as any, I suppose, to advertise the patch I'm
working on and ask for suggestions on the approach.
I'm working on fixing quite a few of these problems right now -- started
with the signals problem, but since my signal fixes will make a proper
/proc implementation easy I will do that as well. Basically, the problem
(for those of you who aren't familiar) is that POSIX says a signal sent to
a process will be handled by any thread that doesn't have it blocked.
Currently, since different threads have different PID's, a signal sent to
a process is implicitly directed at a specific thread -- if that thread
blocks the signal, then POSIX semantics are broken.
My fix is to add a 'struct process_struct' (not to be confused with the
similarly named thing that got renamed to struct task_struct) which is
reused when CLONE_PID is specified. I will add another hash table of
pid -> process_struct, and when a signal is sent to a process, I look up
the process rather than task, and then find a task belonging to that
process that isn't blocking the signal, and deliver the signal to that
task. I'd also have to add a new syscall for pthread_kill to work
properly.
I am also planning on fixing /proc with CLONE_PID by making procfs scan
the process list rather than the task list, and only add one directory
entry per process. Tasks can then be represented as a subdirectory within
a process directory... and for backwards compatibility I suppose I'll grab
the rest of proc information from the first task and put it in the base
process directory. Since most proc-based info is cloned anyway for
threads, this means that a non-thread-aware ps will work properly in
"most" situations. A thread-aware ps can ignore the backward
compatibility issues and look at the properties of each individual
"thread" (which is really more than a thread because it has the
flexibility to have its own address space, etc.) Some time (Linux 5.0 or
something like that) we can remove the "backwards compatible" files
like, say, /proc/101/mem, since different tasks in process 101 can really
have different address spaces... ps should use /proc/101/1/mem instead (to
get the address space of thread id 1 in process 101).
I think the above fixes some problems without losing the flexibility of
cloning over LWPs.
Any comments or objections to this approach.
Chris Smith <cd_smith@ou.edu>
PS: Any other problems to fix with CLONE_PID? I tried searching
linux-kernel, and only found a mention of the duplicate proc directories
problem.
-
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/