> -----Original Message-----
> From: Alan Cox [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 29, 2000 2:08 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Anyone working on multi-threaded core files for 2.4 ?
>
>
> > > while the dump is taken? How about thread A coredumping,
> half of the image
> > > being already written and thread B (nowhere near the
> kernel mode, mind
> > > you) changing the data both in the area that is already
> dumped and area
> > > the still isn't? After that you can look at the dump and
> notice absolutely
> > > corrupted data structures - very effective in
> misdirecting your attempts
> > > to figure out what went wrong.
> >
> > Couldn't all threads be stopped before coredumping begins?
>
> Unless I am missing something doesn't a truncate of a file in
> parallel also
> yank the pages from under the dump too
>
a "good enough" bit of coherence for dumping, it seems to me, can be met by
insuring that none of the threads in the "process" are scheduled against a
CPU during the dump. On a UP this can be relatively simple to do by making
sure that each related thread is kept off the run queue while the dump
occurs, since it is known that none of the non-failing threads were running
when the dump started. On an MP you must also make sure that none of the
threads are running on any of the other processors when the dump starts.
Once all of the threads are stopped, then an "normal" dump is enough,
augmented by (optionaly) dumping the thread-specific state (ie PCB and
stack) of all of the threads in the "process."
Open question: whether or not to allow the remaining threads to continue
once the dump is completed, to abort them, or to signal them. Probably
should be run time configurable.
Marty
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
