[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201030193124.7a1ba64e@oasis.local.home>
Date: Fri, 30 Oct 2020 19:31:24 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Jesper Dangaard Brouer <brouer@...hat.com>,
Peter Zijlstra <peterz@...radead.org>, mingo@...nel.org,
linux-kernel@...r.kernel.org, kan.liang@...ux.intel.com,
acme@...nel.org, mark.rutland@....com,
alexander.shishkin@...ux.intel.com, jolsa@...hat.com,
namhyung@...nel.org, ak@...ux.intel.com, eranian@...gle.com
Subject: Re: [PATCH 4/6] perf: Optimize get_recursion_context()
On Fri, 30 Oct 2020 23:14:18 +0100
Thomas Gleixner <tglx@...utronix.de> wrote:
> On Fri, Oct 30 2020 at 16:22, Steven Rostedt wrote:
> > As this is something that ftrace recursion also does, perhaps we should
> > move this into interrupt.h so that anyone that needs a counter can get
>
> Not in interrupt.h please. We should create kernel/include/ for stuff
> which really should only be available in the core kernel code.
>
The recursion protection is needed for anything that registers a
callback to ftrace. I have patches that already basically do the same
thing (although, with branches) that I'm going to place in
include/linux/trace_recursion.h, so that there are helper functions
that ftrace callbacks can use, instead of having to implement their own
recursion protection. After fixing two bugs in the recursion protection
code, it's something that should be reused, instead of everyone making
similar mistakes.
Note, I thought that in_nmi() and friends was in interrupt.h, but is
really in preempt.h. All the values used in Peter's code is also
defined in preempt.h, so why not have something like that there?
I take back adding it to interrupt.h but have it in preempt.h, as it's
not defining anything new there.
-- Steve
Powered by blists - more mailing lists