[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170930050817.2a0147ba@vmware.local.home>
Date: Sat, 30 Sep 2017 05:08:17 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Joel Fernandes <joelaf@...gle.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>, kernel-team@...roid.com
Subject: Re: [PATCH v6 2/2] tracing: Add support for preempt and irq
enable/disable events
On Mon, 25 Sep 2017 17:23:00 -0700
Joel Fernandes <joelaf@...gle.com> wrote:
> The trace_hardirqs_off API can be called even when IRQs are already
> off. This is unlike the trace_hardirqs_on which checks if IRQs are off
> (atleast from some callsites), here are the definitions just for
> reference [1]. I guess we could modify local_irq_disable and
> local_irq_save to check what the HW flags was before calling
> raw_local_irq_save and only then call trace_hardirqs_off if they were
> indeed on and now being turned off, but that adds complexity to it -
> also we have to then modify all the callsites from assembly code to
> conditionally call trace_hardirqs_on/off :(.
>
> [1] http://elixir.free-electrons.com/linux/latest/source/include/linux/irqflags.h#L89
Yeah, I think the issue for the recursion is basically this:
#define local_irq_restore(flags) \
do { \
if (raw_irqs_disabled_flags(flags)) { \
raw_local_irq_restore(flags); \
trace_hardirqs_off(); \
} else { \
trace_hardirqs_on(); \
raw_local_irq_restore(flags); \
} \
} while (0)
Peter,
Is there any place where we would call local_irq_restore() when
interrupts are enabled?
-- Steve
Powered by blists - more mailing lists