[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240318154300.GA816320@dev-arch.thelio-3990X>
Date: Mon, 18 Mar 2024 08:43:00 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Naresh Kamboju <naresh.kamboju@...aro.org>
Cc: Netdev <netdev@...r.kernel.org>,
clang-built-linux <llvm@...ts.linux.dev>,
open list <linux-kernel@...r.kernel.org>,
lkft-triage@...ts.linaro.org,
"David S. Miller" <davem@...emloft.net>,
Trond Myklebust <trond.myklebust@...merspace.com>,
Eric Dumazet <edumazet@...gle.com>, rostedt@...dmis.org,
linux-trace-kernel@...r.kernel.org
Subject: Re: net/sunrpc/sched.c: error: result of comparison against a string
literal is unspecified (use an explicit string comparison function instead)
Hi Naresh,
On Mon, Mar 18, 2024 at 02:55:54PM +0530, Naresh Kamboju wrote:
> The following build warnings / errors noticed on x86 kselftests build with
> clang nightly / clang-17 on Linux next tag next-20240318.
>
> This build config is generated from kselftest merge configs [1].
>
> Reported-by: Linux Kernel Functional Testing <lkft@...aro.org>
>
> Build log:
> -----------
> In file included from net/sunrpc/sched.c:31:
> In file included from include/trace/events/sunrpc.h:2524:
> In file included from include/trace/define_trace.h:102:
> In file included from include/trace/trace_events.h:419:
> include/trace/events/sunrpc.h:707:4: error: result of comparison
> against a string literal is unspecified (use an explicit string
> comparison function instead) [-Werror,-Wstring-compare]
> 667 | __assign_str(progname,
> | ~~~~~~~~~~~~~~~~~~~~~~
> 668 | task->tk_client->cl_program->name);
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 669 | __entry->version = task->tk_client->cl_vers;
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 670 | __assign_str(procedure,
> task->tk_msg.rpc_proc->p_name);
> |
Thanks for the report. This is caused by commit 433e1d88a3be ("tracing:
Add warning if string in __assign_str() does not match __string()") from
the tracing tree, not a change on the netdev side (although I have left
them on CC for this reply so they are aware of that).
To resolve it, [1] needs to be applied then the following diff can be
applied on top of that to fully clear it up (as __builtin_constant_p()
does not influence diagnostics in the front end, so the warning still
triggers on the else branch when it will really use strcmp(), as Steve
tested at [2]).
[1]: https://lore.kernel.org/20240312113002.00031668@gandalf.local.home/
[2]: https://lore.kernel.org/20240313161420.3b668558@gandalf.local.home/
diff --git a/include/trace/stages/stage6_event_callback.h b/include/trace/stages/stage6_event_callback.h
index 83da83a0c14f..dbd27adb1b83 100644
--- a/include/trace/stages/stage6_event_callback.h
+++ b/include/trace/stages/stage6_event_callback.h
@@ -35,9 +35,14 @@
do { \
char *__str__ = __get_str(dst); \
int __len__ = __get_dynamic_array_len(dst) - 1; \
+ __diag_push(); \
+ __diag_ignore(clang, 13, "-Wstring-compare", \
+ "__builtin_constant_p() ensures strcmp()" \
+ "will be used for string literals"); \
WARN_ON_ONCE(__builtin_constant_p(src) ? \
strcmp((src), __data_offsets.dst##_ptr_) : \
(src) != __data_offsets.dst##_ptr_); \
+ __diag_pop(); \
memcpy(__str__, __data_offsets.dst##_ptr_ ? : \
EVENT_NULL_STR, __len__); \
__str__[__len__] = '\0'; \
Powered by blists - more mailing lists