All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <dan@debian.org>
To: phil-list@redhat.com
Cc: Linus Torvalds <torvalds@transmeta.com>,
	Alexander Viro <viro@math.psu.edu>,
	S Vamsikrishna <vamsi_krishna@in.ibm.com>,
	Mark Gross <markgross@thegnar.org>,
	Ulrich Drepper <drepper@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [patch] thread-aware coredumps, 2.5.43-C3
Date: Thu, 17 Oct 2002 12:40:40 -0400	[thread overview]
Message-ID: <20021017164040.GA12608@nevyn.them.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0210171009240.12653-100000@localhost.localdomain>

On Thu, Oct 17, 2002 at 11:11:21AM +0200, Ingo Molnar wrote:
> - properly wait for all threads that share the same MM to serialize with
>   the coredumping thread. This is CLONE_VM based, not tied to
>   CLONE_THREAD and/or signal semantics, ie. old-style (or different-style)
>   threaded apps will be properly stopped as well.
> 
>   The locking might look a bit complex, but i wanted to keep the
>   __exit_mm() overhead as low as possible. It's not quite trivial to get
>   these bits right, because 'sharing the MM' is detached from signals
>   semantics, so we cannot rely on broadcast-kill catching all threads. So
>   zap_threads() iterates through every thread and zaps those which were
>   left out. (There's a minimal race left in where a newly forked child
>   might escape the attention of zap_threads() - this race is fixed by the
>   OOM fixes in the mmap-speedup patch.)

My only problem with this is that you're waiting for all threads by
SIGKILLing them.  If a process vforks or clones, and then the child
crashes, the parent will receive a SIGKILL - iff we are dumping core. 
That's a change in behavior that seems a bit too arbitrary to me.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

  reply	other threads:[~2002-10-17 16:35 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-08 12:09 [patch] thread-aware coredumps part 1, tcore-2.5.41-A6 Ingo Molnar
2002-10-08 13:30 ` mgross
2002-10-17  9:11   ` [patch] thread-aware coredumps, 2.5.43-C3 Ingo Molnar
2002-10-17 16:40     ` Daniel Jacobowitz [this message]
2002-10-21 14:29       ` Alan Cox
2002-10-21 14:54         ` Daniel Jacobowitz
2002-10-21 16:16           ` Alan Cox
2002-10-21 16:04             ` Daniel Jacobowitz
2002-10-17 21:07     ` mgross
2002-10-18  0:48       ` Daniel Jacobowitz
2002-10-18 13:57         ` Mark Gross
2002-10-18 14:03           ` Mark Gross
2002-10-19 13:26           ` Mark Kettenis
2002-10-19 19:26           ` Bill Davidsen
2002-10-19 19:34             ` Ulrich Drepper
2002-10-19 13:20         ` Mark Kettenis
2002-10-19 18:42           ` Mark Gross
2002-10-18  1:10     ` Andi Kleen
2002-10-18  1:35       ` Mark Gross
2002-10-18  2:12         ` Andi Kleen
2002-10-18  2:58           ` Mark Gross
2002-10-18  3:55             ` Daniel Jacobowitz
2002-10-18 14:00               ` mgross
2002-10-21 15:17             ` Pavel Machek
2002-11-03  7:32               ` Ulrich Drepper
2002-10-19 17:32     ` Ulrich Drepper
2002-10-18  2:23   ` Ulrich Drepper
2002-10-18  2:40     ` Andi Kleen
2002-10-08 18:04 ` [patch] thread-aware coredumps part 1, tcore-2.5.41-A6 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=20021017164040.GA12608@nevyn.them.org \
    --to=dan@debian.org \
    --cc=drepper@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markgross@thegnar.org \
    --cc=phil-list@redhat.com \
    --cc=torvalds@transmeta.com \
    --cc=vamsi_krishna@in.ibm.com \
    --cc=viro@math.psu.edu \
    /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.