Re: [PATCH] x86/traps: Don't for in_interrupt() to return true in IST handlers

[Peter Zijlstra <peterz@infradead.org>]

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 <luto@kernel.org>

> +/*
> + * 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.