On Sat, Sep 30, 2000 at 03:07:57PM -0400, Alexander Viro wrote:
>
>
> On Sat, 30 Sep 2000, James Cownie wrote:
>
> > I was expecting to take the Posix thread style viewpoint in which any
> > of the core dumping signals kill the _process_, so all of the threads
> > are necessarily dead thereafter since they have nowhere to live any
> > longer.
>
> Different model. Threads are _not_ parts of process, they are processes
> that happen to share a component (VM).
The tcore concept in one of the multithreaded coredump patches looks
quite useful actually [queueing the registers and then it is dumped by
a single thread]. They just got it wrong by using a global list, using
pgroup and not using an good mechanism to garbage collect tcores.
Queueing the tcores in the mm_struct could work though. Add a prctl [1]
that enables tcore core dumping. When tcore core dumping is enabled every
core dump that would dump a mm_struct with reference count > 1 does not
actually dump it, but just queues a structure (tqueue) with its registers/
signal info/etc. into a list in the mm_struct. When a thread dumps and
the mm_struct count is 1 then dump a normal core file with all the tcores
as thread notes. Also clean up all the cores then when freeing the mm_struct.
This queueing has to be limited of course, probably by an ulimit. The prctl
could also set an limit.
The question is just what information to put into the tqueue structure.
Everything that can be expressed by a elf_phdr is probably a good start.
There are not more races than in normal core dumping.
This model is generally enough to fit into the Linux clone model.
-Andi
[1] I think a prctl is better than a clone flag here because it keeps the
business of crashing out of the fast paths.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Oct 07 2000 - 21:00:07 EST