[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200623152450.GM4817@hirez.programming.kicks-ass.net>
Date: Tue, 23 Jun 2020 17:24:50 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Ahmed S. Darwish" <a.darwish@...utronix.de>
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 05:00:31PM +0200, Ahmed S. Darwish wrote:
> 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?
That would only legitimize lockdep_off(). The only comment I want to put
on that is: "if you use this, you're doing it wrong'.
Powered by blists - more mailing lists