Received-SPF: pass (google.com: domain of linux-kernel+bounces-107832-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240318113053.7f87ce7f@gandalf.local.home>
In-Reply-To: <20240318113053.7f87ce7f@gandalf.local.home>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 19 Mar 2024 09:23:10 -0700
Message-ID: <CAHk-=wjxX16kWd=uxG5wzqt=aXoYDf1BgWOKk+qVmAO0zh7sjA@mail.gmail.com>
Subject: Re: [GIT PULL v2] tracing: Updates for v6.9
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>, Masami Hiramatsu <mhiramat@kernel.org>, 
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, 
	Alison Schofield <alison.schofield@intel.com>, Beau Belgrave <beaub@linux.microsoft.com>, 
	Huang Yiwei <quic_hyiwei@quicinc.com>, John Garry <john.g.garry@oracle.com>, 
	Randy Dunlap <rdunlap@infradead.org>, Thorsten Blum <thorsten.blum@toblux.com>, 
	Vincent Donnefort <vdonnefort@google.com>, linke li <lilinke99@qq.com>
Content-Type: text/plain; charset="UTF-8"

On Mon, 18 Mar 2024 at 08:28, Steven Rostedt <rostedt@goodmis.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