From: Keith Owens <kaos@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [patch 2.6.10-rc3] Add TIF_SIGDELAYED processing
Date: Thu, 09 Dec 2004 01:41:33 +0000 [thread overview]
Message-ID: <5351.1102556493@ocs3.ocs.com.au> (raw)
In-Reply-To: <15449.1102482344@kao1.melbourne.sgi.com>
On Wed, 8 Dec 2004 17:22:27 -0800,
David Mosberger <davidm@napali.hpl.hp.com> wrote:
>>>>>> On Wed, 08 Dec 2004 16:05:44 +1100, Keith Owens <kaos@sgi.com> said:
>
> Keith> Some of the work on recoverable MCA events has a requirement
> Keith> to send a signal to a user process. But it is not safe to
> Keith> send signals from MCA/INIT/NMI/PMI, because the rest of the
> Keith> kernel is an unknown state. This patch adds set_sigdelayed()
> Keith> which is called from the problem contexts to set the delayed
> Keith> signal. The delayed signal will be delivered from the right
> Keith> context on the next transition from kernel to user space.
>
> Keith> If TIF_SIGDELAYED is set when we run ia64_leave_kernel or
> Keith> ia64_leave_syscall then the delayed signal is delivered and
> Keith> cleared. All code for sigdelayed processing is on the slow
> Keith> paths.
>
> Keith> A recoverable MCA handler that wants to kill a user task just
> Keith> does
>
> Keith> set_sigdelayed(pid, signo, code, addr);
>
>It seems rather dangerous to stash away PIDs and deliver signals to
>them later on. It's just an invitation for races, IMHO.
The pid is checked to see if it is still valid, see do_sigdelayed().
Yes, there is a very small race where the pid could be reused, but to
hit that race we have to -
* Terminate the failing task with that pid.
* Either of the current task or the idle task must sleep for a period
that is long enough for the failing pid to be reassigned and
* The new task with the failing pid must be running when the current or
idle task is rescheduled for the first time.
The pids recycle with a period of approximately 0x8000. It is highly
unlikely that the current or idle task will sleep for that long,
especially since the current task is usually the one that caused the
MCA so it gets killed anyway.
To make it really safe, I can save the start_time from the offending
task in struct sigdelayed and only send the signal if the saved value
matches the start_time of the task that currently has this pid. It
just takes a little more space.
next prev parent reply other threads:[~2004-12-09 1:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-08 5:05 [patch 2.6.10-rc3] Add TIF_SIGDELAYED processing Keith Owens
2004-12-08 17:11 ` Luck, Tony
2004-12-09 1:10 ` Keith Owens
2004-12-09 1:22 ` David Mosberger
2004-12-09 1:41 ` Keith Owens [this message]
2004-12-09 23:08 ` David Mosberger
2004-12-09 23:19 ` Luck, Tony
2004-12-09 23:22 ` David Mosberger
2004-12-10 0:28 ` Jesse Barnes
2004-12-10 1:21 ` Keith Owens
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=5351.1102556493@ocs3.ocs.com.au \
--to=kaos@sgi.com \
--cc=linux-ia64@vger.kernel.org \
/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