linux-kernel - Re: [GIT PULL v2] tracing: Updates for v6.9

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] [thread-next>] [day] [month] [year] [list]

Date: Tue, 19 Mar 2024 09:23:10 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Masami Hiramatsu <mhiramat@...nel.org>, 
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, 
	Alison Schofield <alison.schofield@...el.com>, Beau Belgrave <beaub@...ux.microsoft.com>, 
	Huang Yiwei <quic_hyiwei@...cinc.com>, John Garry <john.g.garry@...cle.com>, 
	Randy Dunlap <rdunlap@...radead.org>, Thorsten Blum <thorsten.blum@...lux.com>, 
	Vincent Donnefort <vdonnefort@...gle.com>, linke li <lilinke99@...com>
Subject: Re: [GIT PULL v2] tracing: Updates for v6.9

On Mon, 18 Mar 2024 at 08:28, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> - Added checks to make sure that the source of __string() is also the
>   source of __assign_str() so that it can be safely removed in the next
>   merge window.

Aargh.

I didn't notice this initially, because it doesn't happen with gcc (or
maybe not with allmodconfig), but with clang I get

    CC [M]  net/sunrpc/sched.o
  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]

and then about 250 lines ot messy "explanations" for how it was
expanded because it happens on line 709 too in the same macro, and it
ends up being three macros deep or something.

So no, this all needs to be re-done. That

                WARN_ON_ONCE(__builtin_constant_p(src) ?                \
                             strcmp((src), __data_offsets.dst##_ptr_) : \
                             (src) != __data_offsets.dst##_ptr_);       \

does *NOT* work.

Also, looking at that __assign_str() macro, it seems literally insane.
On the next line it will do

                memcpy(__str__, __data_offsets.dst##_ptr_ ? :           \
                       EVENT_NULL_STR, __len__);                        \

so now it checks "__data_offsets.dst##_ptr_" for NULL - but that's one
line after it just did that strcmp on it.

WTF?

This code is completely bogus.

               Linus