From: Rusty Russell <rusty@rustcorp.com.au>
To: Roland McGrath <roland@redhat.com>
Cc: Andrew Morton <akpm@osdl.org>,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jeremy Kerr <jk@ozlabs.org>
Subject: Re: [PATCH] Fix signal race during process exit
Date: Thu, 10 Jun 2004 12:51:13 +1000 [thread overview]
Message-ID: <1086835873.27404.362.camel@bach> (raw)
In-Reply-To: <200406100148.i5A1mwHl009763@magilla.sf.frob.com>
On Thu, 2004-06-10 at 11:48, Roland McGrath wrote:
> The concern I had is basically that this might not be true of all cases.
> The only problem case that has come up is the current task's own interrupt
> handlers calling signal code while interrupting release_task. I know for
> the case of posix-timers it's not an issue because their cleanup is handled
> with special synchronization in __exit_signal. What I'm not sure about is
> all other sources of asynchronous signals that use task_struct pointers
> rather than PID lookups and so might do one while release_task is in progress.
> e.g. async IO signals triggered via driver interrupts, etc.
Yes. In 2.4 we explicitly checked in the signal code.
Why don't we do the sane thing and just do release_task() from
__put_task_struct(), rather than the current two-stage thing?
Rusty.
--
Anyone who quotes me in their signature is an idiot -- Rusty Russell
next prev parent reply other threads:[~2004-06-10 2:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-04 1:21 [PATCH] Fix signal race during process exit Roland McGrath
2004-06-04 1:30 ` Andrew Morton
2004-06-10 1:48 ` Roland McGrath
2004-06-10 2:20 ` Andrew Morton
2004-06-10 2:51 ` Rusty Russell [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-06-02 2:13 Jeremy Kerr
2004-06-02 5:57 ` Andrew Morton
2004-06-02 6:49 ` Rusty Russell
2004-06-02 7:08 ` Andrew Morton
2004-06-02 7:16 ` Andrew Morton
2004-06-02 8:13 ` Jeremy Kerr
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=1086835873.27404.362.camel@bach \
--to=rusty@rustcorp.com.au \
--cc=akpm@osdl.org \
--cc=jk@ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@redhat.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.