On Tue, Aug 18, 2020 at 05:22:33PM +1000, Nicholas Piggin wrote:

Excerpts from peterz@infradead.org's message of August 12, 2020 8:35 pm:

quoted

On Wed, Aug 12, 2020 at 06:18:28PM +1000, Nicholas Piggin wrote:

quoted

Excerpts from peterz@infradead.org's message of August 7, 2020 9:11 pm:

quoted

What's wrong with something like this?

AFAICT there's no reason to actually try and add IRQ tracing here, it's
just a hand full of instructions at the most.

Because we may want to use that in other places as well, so it would
be nice to have tracing.

Hmm... also, I thought NMI context was free to call local_irq_save/restore
anyway so the bug would still be there in those cases?

NMI code has in_nmi() true, in which case the IRQ tracing is disabled
(except for x86 which has CONFIG_TRACE_IRQFLAGS_NMI).

That doesn't help. It doesn't fix the lockdep irq state going out of
synch with the actual irq state. The code which triggered this with the
special powerpc irq disable has in_nmi() true as well.

Urgh, you're talking about using lockdep_assert_irqs*() from NMI
context?

If not, I'm afraid I might've lost the plot a little on what exact
failure case we're talking about.