Messages in this thread |  | | Date | Sun, 1 Oct 2000 14:06:44 +0200 | From | "Andi Kleen" <> | Subject | Re: Anyone working on multi-threaded core files for 2.4 ? |
| |
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/
|  |