From: Oleg Nesterov <oleg@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org,
linux-rt-users <linux-rt-users@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Carsten Emde <C.Emde@osadl.org>, John Kacur <jkacur@redhat.com>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Alexander van Heukelum <heukelum@fastmail.fm>,
Andi Kleen <ak@linux.intel.com>,
Clark Williams <williams@redhat.com>,
Luis Goncalves <lgoncalv@redhat.com>,
stable-rt@vger.kernel.org
Subject: Re: [PATCH RT 2/2 v4] preempt-rt/x86: Delay calling signals in int3
Date: Sun, 5 Feb 2012 20:23:05 +0100 [thread overview]
Message-ID: <20120205192305.GB12183@redhat.com> (raw)
In-Reply-To: <1328299833.5882.211.camel@gandalf.stny.rr.com>
On 02/03, Steven Rostedt wrote:
>
> If
> we can solve this in a clean way using the existing signal
> infrastructure, I'm all for that.
I am not sure, I know almost nothing about rt and about this
low-level stuff. But please look at my attempt below.
So. it is very simple. The patch simply changes force_sig_info() to
check in_atomic(), if it is true we offload the sending to
do_notify_resume(). Of course, I do not know if we can rely on this
check in rt kernels.
Note:
- The patch adds the new code under CONFIG_PREEMPT_RT_FULL,
it should probably check X86_64 or defined(TIF_NOTIFY_RESUME)
as well.
- I think we can later move task->forced_info into restart_block's
union.
- We could modify get_signal_to_deliver() instead of the
arch-dependant do_notify_resume(). In this case we do not
need TIF_NOTIFY_RESUME, TIF_SIGPENDING is enough.
What do you think?
Oleg.
---
arch/x86/kernel/signal.c | 9 +++++++++
include/linux/sched.h | 4 ++++
kernel/signal.c | 31 +++++++++++++++++++++++++++++--
3 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index 46a01bd..22cb8ff 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -816,6 +816,15 @@ do_notify_resume(struct pt_regs *regs, void *unused, __u32 thread_info_flags)
mce_notify_process();
#endif /* CONFIG_X86_64 && CONFIG_X86_MCE */
+#ifdef CONFIG_PREEMPT_RT_FULL
+ if (unlikely(current->forced_info.si_signo)) {
+ struct task_struct *t = current;
+ force_sig_info(t->forced_info.si_signo,
+ &t->forced_info, t);
+ t->forced_info.si_signo = 0;
+ }
+#endif
+
/* deal with pending signal delivery */
if (thread_info_flags & _TIF_SIGPENDING)
do_signal(regs);
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 2234985..942c545 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1407,6 +1407,10 @@ struct task_struct {
sigset_t blocked, real_blocked;
sigset_t saved_sigmask; /* restored if set_restore_sigmask() was used */
struct sigpending pending;
+#ifdef CONFIG_PREEMPT_RT_FULL
+ /* TODO: move me into ->restart_block ? */
+ struct siginfo forced_info;
+#endif
unsigned long sas_ss_sp;
size_t sas_ss_size;
diff --git a/kernel/signal.c b/kernel/signal.c
index c73c428..5c0b61a 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1228,8 +1228,8 @@ int do_send_sig_info(int sig, struct siginfo *info, struct task_struct *p,
* We don't want to have recursive SIGSEGV's etc, for example,
* that is why we also clear SIGNAL_UNKILLABLE.
*/
-int
-force_sig_info(int sig, struct siginfo *info, struct task_struct *t)
+static int
+do_force_sig_info(int sig, struct siginfo *info, struct task_struct *t)
{
unsigned long int flags;
int ret, blocked, ignored;
@@ -1254,6 +1254,33 @@ force_sig_info(int sig, struct siginfo *info, struct task_struct *t)
return ret;
}
+int force_sig_info(int sig, struct siginfo *info, struct task_struct *t)
+{
+#ifdef CONFIG_PREEMPT_RT_FULL
+ if (in_atomic()) {
+ if (WARN_ON_ONCE(t != current))
+ return 0;
+ if (WARN_ON_ONCE(t->forced_info.si_signo))
+ return 0;
+
+ if (is_si_special(info)) {
+ WARN_ON_ONCE(info != SEND_SIG_PRIV);
+ t->forced_info.si_signo = sig;
+ t->forced_info.si_errno = 0;
+ t->forced_info.si_code = SI_KERNEL;
+ t->forced_info.si_pid = 0;
+ t->forced_info.si_uid = 0;
+ } else {
+ t->forced_info = *info;
+ }
+
+ set_tsk_thread_flag(t, TIF_NOTIFY_RESUME);
+ return 0;
+ }
+#endif
+ return do_force_sig_info(sig, info, t);
+}
+
/*
* Nuke all other threads in the group.
*/
next prev parent reply other threads:[~2012-02-05 19:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-03 18:28 [PATCH RT 0/2 v4] preempt-rt/x86: Handle sending signals from do_trap() by gdb Steven Rostedt
2012-02-03 18:28 ` [PATCH RT 1/2 v4] x86: Do not disable preemption in int3 on 32bit Steven Rostedt
2012-02-03 18:28 ` [PATCH RT 2/2 v4] preempt-rt/x86: Delay calling signals in int3 Steven Rostedt
2012-02-03 18:40 ` Oleg Nesterov
2012-02-03 20:10 ` Steven Rostedt
2012-02-05 19:23 ` Oleg Nesterov [this message]
2012-02-05 19:31 ` Oleg Nesterov
2012-02-06 16:12 ` Steven Rostedt
2012-02-06 16:25 ` Oleg Nesterov
2012-02-06 16:38 ` Steven Rostedt
2012-02-07 14:17 ` Steven Rostedt
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=20120205192305.GB12183@redhat.com \
--to=oleg@redhat.com \
--cc=C.Emde@osadl.org \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=heukelum@fastmail.fm \
--cc=hpa@zytor.com \
--cc=jkacur@redhat.com \
--cc=lgoncalv@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=stable-rt@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=williams@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.