linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roland McGrath <roland@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Anton Blanchard <anton@samba.org>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@digeo.com>, <arjanv@redhat.com>
Subject: Re: heavy handed exit() in latest BK
Date: Sat, 8 Feb 2003 18:17:52 -0800	[thread overview]
Message-ID: <200302090217.h192Hqi04174@magilla.sf.frob.com> (raw)
In-Reply-To: Linus Torvalds's message of  Saturday, 8 February 2003 18:00:01 -0800 <Pine.LNX.4.44.0302081754340.5231-100000@home.transmeta.com>

> By then we also have local interrupts disabled, and we've explicitly 
> disabled preemption, so I don't see how anything could ever wake us up any 
> more. 

We already know how this happens.  I think it's only possible with SMP.  
I described this very problem in the final paragraph of my penultimate
message on the signals changes:

    Incidentally, I've run across another bug introduced by the last rework of
    handle_stop_signal (or perhaps similar races have always been there, I'm
    not quite sure at the moment).  It can call wake_up_process on a zombie
    that's on its way to exit, triggering the BUG at the end of do_exit.  I
    think this race may be possible in all of the signal_wake_up calls for
    SIGKILL cases, and other uses of wake_up_process like PTRACE_KILL.
    Some such places check ->state, but they do not lock out exit races.
    Perhaps having wake_up_process itself be race-proof would be simplest.
    I don't have a good sense of how best to fix this one yet.

This will probably stop biting anyone in practice after the most recent new
plan for SIGKILL we've just been discussing.  For signals, the race will
only be possible for SIGCONT sent when a thread is on its way to die.  That
can be avoided by checking PF_EXITING in handle_stop_signal, because after
setting PF_EXITING any thread in do_exit will take the siglock and thus
can't have gotten far enough to go to TASK_ZOMBIE without being serialized
after the loop in handle_stop_signal.

As I said above, I think this race is possible in other uses of
wake_up_process.  PTRACE_KILL is one example, but there are others and I
would have to check carefully to be convinced that other factors rule out
this exit race for them.  I think that BUG_ON check should definitely go
into try_wake_up so that it hits should any of these other races ever
actually bite.  Unless I am missing something, it won't necessarily catch
all races unless you use xchg to set TASK_RUNNING and then check the old value.

  reply	other threads:[~2003-02-09  2:08 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-09  0:57 heavy handed exit() in latest BK Anton Blanchard
2003-02-09  2:00 ` Linus Torvalds
2003-02-09  2:17   ` Roland McGrath [this message]
2003-02-09  2:19     ` Linus Torvalds
2003-02-09  2:31       ` Roland McGrath
2003-02-09  2:34         ` Linus Torvalds
2003-02-09  2:33   ` Linus Torvalds
2003-02-09  2:41     ` Roland McGrath
2003-02-09  3:30     ` Roland McGrath
2003-02-09  3:33       ` Roland McGrath
2003-02-09  3:37         ` Linus Torvalds
2003-02-09  3:40           ` Linus Torvalds
2003-02-09  3:48         ` Roland McGrath
2003-02-09  4:51           ` Linus Torvalds
2003-02-09  4:57             ` Linus Torvalds
2003-02-09  5:00             ` Roland McGrath
2003-02-09  9:28             ` Russell King
2003-02-10  8:53   ` Ingo Molnar
2003-02-10 15:22     ` Linus Torvalds
     [not found] <200302091130.h19BU2107744@magilla.sf.frob.com>
2003-02-09 11:40 ` Ingo Molnar
2003-02-09 11:56   ` Roland McGrath
2003-02-09 12:09     ` Ingo Molnar
2003-02-09 12:18     ` Ingo Molnar
2003-02-09 12:23       ` Ingo Molnar
2003-02-09 12:22         ` Arjan van de Ven
2003-02-10  1:07     ` Linus Torvalds
2003-02-10  1:27       ` Roland McGrath

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=200302090217.h192Hqi04174@magilla.sf.frob.com \
    --to=roland@redhat.com \
    --cc=akpm@digeo.com \
    --cc=anton@samba.org \
    --cc=arjanv@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@transmeta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).