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@xxxxxxxxxxxxxxx
> Fixes: 959274753857 ("x86, traps: Track entry into and exit from IST context")
> Signed-off-by: Andy Lutomirski <luto@xxxxxxxxxx>
> +/*
> + * 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.
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html