lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ