From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oleg Nesterov Subject: Re: [PATCH RT 2/2 v4] preempt-rt/x86: Delay calling signals in int3 Date: Sun, 5 Feb 2012 20:31:46 +0100 Message-ID: <20120205193146.GC12183@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-kernel@vger.kernel.org, linux-rt-users , Thomas Gleixner , Carsten Emde , John Kacur , Masami Hiramatsu , Ingo Molnar , Andrew Morton , "H. Peter Anvin" , Alexander van Heukelum , Andi Kleen , Clark Williams , Luis Goncalves , stable-rt@vger.kernel.org To: Steven Rostedt Return-path: Content-Disposition: inline In-Reply-To: <20120205192305.GB12183@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-rt-users.vger.kernel.org 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.