- Subject: Re: [PATCH RT 2/2 v4] preempt-rt/x86: Delay calling signals in int3
- From: Oleg Nesterov <oleg@xxxxxxxxxx>
- Date: Sun, 5 Feb 2012 20:31:46 +0100
- Cc: linux-kernel@xxxxxxxxxxxxxxx, linux-rt-users <linux-rt-users@xxxxxxxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Carsten Emde <C.Emde@xxxxxxxxx>, John Kacur <jkacur@xxxxxxxxxx>, Masami Hiramatsu <masami.hiramatsu.pt@xxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Alexander van Heukelum <heukelum@xxxxxxxxxxx>, Andi Kleen <ak@xxxxxxxxxxxxxxx>, Clark Williams <williams@xxxxxxxxxx>, Luis Goncalves <lgoncalv@xxxxxxxxxx>, stable-rt@xxxxxxxxxxxxxxx
- In-reply-to: <20120205192305.GB12183@redhat.com>
- References: <20120203182853.547078531@goodmis.org> <20120203183041.427463295@goodmis.org> <20120203184016.GA10413@redhat.com> <1328299833.5882.211.camel@gandalf.stny.rr.com> <20120205192305.GB12183@redhat.com>
- User-agent: Mutt/1.5.18 (2008-05-17)
Damn. Sorry for noise...
On 02/05, Oleg Nesterov wrote:
>
> +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))
This is certainly wrong in upstream kernel. It does use force_
this way although it shouldn't imho.
But _probably_ this is fine for rt? We are going to take the mutex,
we shouldn't do this in atomic context. But, once again, I do not
really know what in_atomic() means in rt.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe stable-rt" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Corosync Project]
[Linux USB Devel]
[Video for Linux]
[Linux Audio Users]
[Photo]
[Yosemite News]
[Yosemite Photos]
[Free Online Dating]
[Linux Kernel]
[Linux SCSI]
[XFree86]