From: Roberto Fichera <kernel@tekno-soft.it>
To: mgross@unix-os.sc.intel.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: Multithreaded coredump patch where?
Date: Thu, 19 Dec 2002 10:24:45 +0100 [thread overview]
Message-ID: <5.2.0.9.0.20021219095902.04868d90@mail.isolaweb.it> (raw)
In-Reply-To: <200212181907.gBIJ7XP12936@unix-os.sc.intel.com>
At 08.13 18/12/02 -0800, mgross wrote:
>On Tuesday 17 December 2002 03:05 am, Roberto Fichera wrote:
> > >I haven't rebased the patches I posted back in June for a while now.
> > >
> > >Attached is the patch I posted for the 2.4.18 vanilla kernel. Its a bit
> > >controversial, but it seems to work for a number of folks. Let me know if
> > >you have any troubles re-basing it.
> >
> > Only one hunk failed on include/asm-ia64/elf.h but fixed by hand.
> > Why do you say a bit controversial ? One difference that I have
> > notice is in coredump size after your patch. However seem to be
> > working well for now. I'll try later on a SMP machine.
>
>There are 2 issues with this implementation that will likely not effect you.
>
>
>First, when dumping core of MT applications with LOTS of threads the pthread
>library signals all the threads in the application to exit. Sometimes
>the process that is dumping core fails to suspend other threads in the
>application before some exit. The result of this is that for such
>applications you will not see them in the core file.
>
>You have to work at it to see this failure. The way I reproduce this is to
>run a test application with about 555 pthread threads in it and send it a
>sig_quit. When I look at the core file wont have all 555 threads. SMP makes
>this effect a bit more noticeable.
This could be a problem for me. I haven't tried yet your patch with my SMP
machine but I'll try today, I hope.
>Ingo's design to fix this change the exit path for thread to wait for the
>core file to get dumped before finishing the process clean up. I like this
>approach, I just wish I thought of it ;)
Yes seem to be a good solution.
>Second, the controversial issue is in the way my design pauses the other
>threads in the MT application. Its not semaphore lock safe. Although no
>instance of the following failure has been seen, it is possible with new
>kernel code.
>
>If one of the processes in the MT application is currently holding semaphore
>lock when the dumping process pauses it, AND the dumping process does any
>blocking operation that could attempt to grab this same semaphore, THEN the
>core dump will deadlock. Boom.
This problem could be reproducible under load doing some IO (fs & net),
cpu bound process and swapping (vm IO). In this way we could have some
possibility to catch it.
>My patch is good for developers, pending the back port of Ingo's version.
>
>Do let me know how it works out for you.
>
>--mgross
Roberto Fichera.
next prev parent reply other threads:[~2002-12-19 9:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-16 17:28 Multithreaded coredump patch where? Roberto Fichera
2002-12-16 21:21 ` mgross
2002-12-17 11:05 ` Roberto Fichera
2002-12-17 12:05 ` Arjan van de Ven
2002-12-17 12:51 ` Roberto Fichera
2002-12-17 12:08 ` Arjan van de Ven
2002-12-18 16:13 ` mgross
2002-12-19 9:24 ` Roberto Fichera [this message]
2002-12-17 12:14 ` Arjan van de Ven
2002-12-18 16:19 ` mgross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5.2.0.9.0.20021219095902.04868d90@mail.isolaweb.it \
--to=kernel@tekno-soft.it \
--cc=linux-kernel@vger.kernel.org \
--cc=mgross@unix-os.sc.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.