linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"kernel test robot" <lkp@intel.com>
Cc: "Arnd Bergmann" <arnd@kernel.org>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Masami Hiramatsu" <mhiramat@kernel.org>,
	"Simon Horman" <horms@kernel.org>,
	"Jeff Layton" <jlayton@kernel.org>,
	"Anna Schumaker" <anna.schumaker@oracle.com>,
	"Chuck Lever" <chuck.lever@oracle.com>,
	llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
	"Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Linux Memory Management List" <linux-mm@kvack.org>,
	"Randy Dunlap" <rdunlap@infradead.org>,
	"Yury Norov" <ynorov@nvidia.com>,
	"Joel Fernandes" <joelagnelf@nvidia.com>,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH] tracing: remove __printf() attribute on __ftrace_vbprintk()
Date: Tue, 03 Feb 2026 16:56:03 +0100	[thread overview]
Message-ID: <d777a8f0-41ab-48f8-93db-268f493ac656@app.fastmail.com> (raw)
In-Reply-To: <aYINAPJS9zXlUGCw@smile.fi.intel.com>

On Tue, Feb 3, 2026, at 15:58, Andy Shevchenko wrote:
> On Tue, Feb 03, 2026 at 08:12:57PM +0800, kernel test robot wrote:
>
>> kernel test robot noticed the following build warnings:
>
> Yeah, you need to go for the full stack of these calls and mark the 
> bottom one with __diag() to avoid these warnings. That's my understanding
> and what BPF people required. Chasing this one-by-one would produce
> unneeded churn.

From what I can tell, I can just move the printf attribute
to the __ftrace_vbprintk() definition to make this bit work.
I'll send an updated patch:

--- a/kernel/trace/trace_printk.c
+++ b/kernel/trace/trace_printk.c
@@ -197,6 +197,7 @@ struct notifier_block module_trace_bprintk_format_nb = {
        .notifier_call = module_trace_bprintk_format_notify,
 };
 
+__printf(2, 3)
 int __trace_bprintk(unsigned long ip, const char *fmt, ...)
 {
        int ret;

There are unrelated warnings for BPF that I managed to
shut up the same way, doing

diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index b54ec0e945aa..45d026fc4e8a 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -1046,6 +1046,7 @@ int bpf_bprintf_prepare(const char *fmt, u32 fmt_size, const u64 *raw_args,
        return err;
 }
 
+__printf(3, 0)
 BPF_CALL_5(bpf_snprintf, char *, str, u32, str_size, char *, fmt,
           const void *, args, u32, data_len)
 {
diff --git a/kernel/bpf/stream.c b/kernel/bpf/stream.c
index 24730df55e69..816fd7fba3d2 100644
--- a/kernel/bpf/stream.c
+++ b/kernel/bpf/stream.c
@@ -212,6 +212,7 @@ __bpf_kfunc_start_defs();
  * Avoid using enum bpf_stream_id so that kfunc users don't have to pull in the
  * enum in headers.
  */
+__printf(2, 0)
 __bpf_kfunc int bpf_stream_vprintk(int stream_id, const char *fmt__str, const void *args,
                                   u32 len__sz, struct bpf_prog_aux *aux)
 {
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index eadaef8592a3..2d3de71ab86a 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -359,6 +359,7 @@ static const struct bpf_func_proto bpf_probe_write_user_proto = {
 #define MAX_TRACE_PRINTK_VARARGS       3
 #define BPF_TRACE_PRINTK_SIZE          1024
 
+__printf(1, 0)
 BPF_CALL_5(bpf_trace_printk, char *, fmt, u32, fmt_size, u64, arg1,
           u64, arg2, u64, arg3)
 {
@@ -412,6 +413,7 @@ const struct bpf_func_proto *bpf_get_trace_printk_proto(void)
        return &bpf_trace_printk_proto;
 }
 
+__printf(1, 0)
 BPF_CALL_4(bpf_trace_vprintk, char *, fmt, u32, fmt_size, const void *, args,
           u32, data_len)
 {
@@ -455,6 +457,7 @@ const struct bpf_func_proto *bpf_get_trace_vprintk_proto(void)
        return &bpf_trace_vprintk_proto;
 }
 
+__printf(2, 0)
 BPF_CALL_5(bpf_seq_printf, struct seq_file *, m, char *, fmt, u32, fmt_size,
           const void *, args, u32, data_len)
 {

Since those functions have no callers, the annotation on the
print functions does nothing.

With those added, and a couple of drivers fixed to use the
correct printf attributes, the only remaining one I see is
in samples/trace_events/trace-events-sample.h:

In file included from /home/arnd/arm-soc/include/trace/define_trace.h:132,
                 from /home/arnd/arm-soc/samples/trace_events/trace-events-sample.h:640,
                 from /home/arnd/arm-soc/samples/trace_events/trace-events-sample.c:12:
/home/arnd/arm-soc/samples/trace_events/./trace-events-sample.h: In function 'trace_event_get_offsets_foo_bar':
/home/arnd/arm-soc/include/trace/stages/stage5_get_offsets.h:33:31: error: function 'trace_event_get_offsets_foo_bar' might be a candidate for 'gnu_printf' format attribute [-Werror=suggest-attribute=format]
   33 |         { (void)sizeof(struct _test_no_array_##item *); }
      |                               ^~~~~~~~~~~~~~~
/home/arnd/arm-soc/include/trace/trace_events.h:285:9: note: in definition of macro 'DECLARE_EVENT_CLASS'
  285 |         tstruct;                                                        \
      |         ^~~~~~~
/home/arnd/arm-soc/include/trace/trace_events.h:43:30: note: in expansion of macro 'PARAMS'
   43 |                              PARAMS(tstruct),                  \
      |                              ^~~~~~
/home/arnd/arm-soc/samples/trace_events/./trace-events-sample.h:291:1: note: in expansion of macro 'TRACE_EVENT'
  291 | TRACE_EVENT(foo_bar,
      | ^~~~~~~~~~~
/home/arnd/arm-soc/samples/trace_events/./trace-events-sample.h:299:9: note: in expansion of macro 'TP_STRUCT__entry'
  299 |         TP_STRUCT__entry(
      |         ^~~~~~~~~~~~~~~~
/home/arnd/arm-soc/samples/trace_events/./trace-events-sample.h:301:17: note: in expansion of macro '__field'
  301 |                 __field(        int,    bar                     )
      |                 ^~~~~~~
/home/arnd/arm-soc/samples/trace_events/./trace-events-sample.h: In function 'do_trace_event_raw_event_foo_bar':

I don't think this is related, but I also don't see an obvious
workaround other than forcing the warning off around that
definition.

       Arnd


  reply	other threads:[~2026-02-03 15:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260202095834.1328352-1-arnd@kernel.org>
2026-02-03 12:12 ` kernel test robot
2026-02-03 14:58   ` Andy Shevchenko
2026-02-03 15:56     ` Arnd Bergmann [this message]
2026-02-03 17:17       ` Andy Shevchenko

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=d777a8f0-41ab-48f8-93db-268f493ac656@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=anna.schumaker@oracle.com \
    --cc=arnd@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=horms@kernel.org \
    --cc=jlayton@kernel.org \
    --cc=joelagnelf@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=llvm@lists.linux.dev \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=rdunlap@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=ynorov@nvidia.com \
    /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