[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1597735273.s0usqkrlsk.astroid@bobo.none>
Date: Tue, 18 Aug 2020 17:22:33 +1000
From: Nicholas Piggin <npiggin@...il.com>
To: peterz@...radead.org
Cc: Alexey Kardashevskiy <aik@...abs.ru>, linux-arch@...r.kernel.org,
linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>
Subject: Re: [PATCH 1/2] lockdep: improve current->(hard|soft)irqs_enabled
synchronisation with actual irq state
Excerpts from peterz@...radead.org's message of August 12, 2020 8:35 pm:
> On Wed, Aug 12, 2020 at 06:18:28PM +1000, Nicholas Piggin wrote:
>> Excerpts from peterz@...radead.org's message of August 7, 2020 9:11 pm:
>> >
>> > 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.
Thanks,
Nick
Powered by blists - more mailing lists