From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([198.137.202.9]:53394 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754912AbcEXJAH (ORCPT ); Tue, 24 May 2016 05:00:07 -0400 Date: Tue, 24 May 2016 10:59:45 +0200 From: Peter Zijlstra To: Andy Lutomirski Cc: x86@kernel.org, Borislav Petkov , Andi Kleen , lkml@vger.kernel.org, Oleg Nesterov , stable@vger.kernel.org Subject: Re: [PATCH] x86/traps: Don't for in_interrupt() to return true in IST handlers Message-ID: <20160524085945.GE3192@twins.programming.kicks-ass.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: stable-owner@vger.kernel.org List-ID: On Mon, May 23, 2016 at 08:57:05PM -0700, Andy Lutomirski wrote: > Forcing in_interrupt() to return true if we're not in a bona fide > interrupt confuses the softirq code. This fixes warnings like: > > NOHZ: local_softirq_pending 282 > > that can happen when running things like selftests/x86. > > Cc: stable@vger.kernel.org > Fixes: 959274753857 ("x86, traps: Track entry into and exit from IST context") > Signed-off-by: Andy Lutomirski > +/* > + * We want to cause in_atomic() to return true while in an IST handler > + * so that attempts to schedule will warn. > + * > + * We cannot add use HARDIRQ_OFFSET or otherwise cause in_interrupt() to > + * return true: the softirq code assumes that in_interrupt() only > + * returns true if we will soon execute softirqs, and we can't do that > + * if an IST entry interrupts kernel code with interrupts disabled. > + * > + * Using 3 * PREEMPT_OFFSET instead of just PREEMPT_OFFSET is pure > + * paranoia. > + */ > +#define IST_OFFSET (3 * PREEMPT_OFFSET) So this has implications for code like kernel/events/internal.h:get_recursion_context() and kernel/trace/trace.c:get_trace_buf(). Which use a sequence of: in_nmi(), in_irq(), in_softirq() to pick 1 out of 4 possible contexts. I would really like the Changelog to reflect on this. The current code will have ISTs land in in_irq(), with this chance, not so much. Now ISTs as a whole invalidate the whole 'we have only 4 contexts' and the mapping back to those 4 is going to be somewhat arbitrary I suspect, but changes like this should be very much aware of these things. And make an explicit choice.