[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230517144409.3f790524@gandalf.local.home>
Date: Wed, 17 May 2023 14:44:09 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Arnd Bergmann <arnd@...nel.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
linux-trace-kernel@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
Kees Cook <keescook@...omium.org>,
Bart Van Assche <bvanassche@....org>,
Sami Tolvanen <samitolvanen@...gle.com>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
linux-sparse@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tracing: make ftrace_likely_update() declaration
visible
On Wed, 17 May 2023 09:39:41 -0700
Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> On Wed, May 17, 2023 at 5:47 AM Arnd Bergmann <arnd@...nel.org> wrote:
> >
> > From: Arnd Bergmann <arnd@...db.de>
> >
> > This function is only used when CONFIG_TRACE_BRANCH_PROFILING is
> > set, and the declaration is hidden behind this Kconfig symbol,
> > which causes a warning if disabled:
>
> That explanation is not very clear.
>
> The problem is that the tracing code itself is built with
> DISABLE_BRANCH_PROFILING, in order to not recurse. And that hides the
> declaration when the definition is compiled, leading to the problem.
>
> CONFIG_TRACE_BRANCH_PROFILING isn't the problem in itself - *that*
> part of the test is consistent (not used, not declared, and not
> compiled if it is off).
>
> The problem is that DISABLE_BRANCH_PROFILING case, where it is used
> elsewhere, but not declared when it is itself compiled.
>
> I applied the patch, but I tried to reword the explanation to be more
> clear. I may have failed.
>
That's pretty much it. The DISABLE_BRANCH_PROFILING is to disable it in
various places where it will crash if used (vdso is one of them). It is
also used to prevent the code that declares it from recursing on itself (as
you stated).
Thus, the issue is simply that the declaration is hidden by the recursion
protection where the function is actually defined.
Reviewed-by: Steven Rostedt (Google) <rostedt@...dmis.org>
-- Steve
Powered by blists - more mailing lists