[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200623150031.GA2986783@debian-buster-darwi.lab.linutronix.de>
Date: Tue, 23 Jun 2020 17:00:31 +0200
From: "Ahmed S. Darwish" <a.darwish@...utronix.de>
To: Peter Zijlstra <peterz@...radead.org>
Cc: mingo@...nel.org, will@...nel.org, tglx@...utronix.de,
x86@...nel.org, linux-kernel@...r.kernel.org, rostedt@...dmis.org,
bigeasy@...utronix.de, davem@...emloft.net,
sparclinux@...r.kernel.org, mpe@...erman.id.au,
linuxppc-dev@...ts.ozlabs.org, heiko.carstens@...ibm.com,
linux-s390@...r.kernel.org, linux@...linux.org.uk
Subject: Re: [PATCH v4 7/8] lockdep: Change hardirq{s_enabled,_context} to
per-cpu variables
On Tue, Jun 23, 2020 at 10:36:52AM +0200, Peter Zijlstra wrote:
...
> -#define lockdep_assert_irqs_disabled() do { \
> - WARN_ONCE(debug_locks && !current->lockdep_recursion && \
> - current->hardirqs_enabled, \
> - "IRQs not disabled as expected\n"); \
> - } while (0)
> +#define lockdep_assert_irqs_enabled() \
> +do { \
> + WARN_ON_ONCE(debug_locks && !this_cpu_read(hardirqs_enabled)); \
> +} while (0)
>
Can we add a small comment on top of lockdep_off(), stating that lockdep
IRQ tracking will still be kept after a lockdep_off call?
thanks,
--
Ahmed S. Darwish
Linutronix GmbH
Powered by blists - more mailing lists