From: Steven Rostedt <rostedt@goodmis.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Arnd Bergmann <arnd@kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
linux-trace-kernel@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
Kees Cook <keescook@chromium.org>,
Bart Van Assche <bvanassche@acm.org>,
Sami Tolvanen <samitolvanen@google.com>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
linux-sparse@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tracing: make ftrace_likely_update() declaration visible
Date: Wed, 17 May 2023 14:44:09 -0400 [thread overview]
Message-ID: <20230517144409.3f790524@gandalf.local.home> (raw)
In-Reply-To: <CAHk-=wh+129KAcegJqvo2PKPUK3yw5qQwF0LcHofdT0bPbs8iQ@mail.gmail.com>
On Wed, 17 May 2023 09:39:41 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Wed, May 17, 2023 at 5:47 AM Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > From: Arnd Bergmann <arnd@arndb.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@goodmis.org>
-- Steve
prev parent reply other threads:[~2023-05-17 18:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 12:47 [PATCH] tracing: make ftrace_likely_update() declaration visible Arnd Bergmann
2023-05-17 16:39 ` Linus Torvalds
2023-05-17 18:44 ` Steven Rostedt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230517144409.3f790524@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=bvanassche@acm.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sparse@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=luc.vanoostenryck@gmail.com \
--cc=mhiramat@kernel.org \
--cc=peterz@infradead.org \
--cc=samitolvanen@google.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox