[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiSdtNvq_wUtq7f3oO7S7BYCeXh7a707HKvK9nVkxR=jQ@mail.gmail.com>
Date: Sat, 14 Dec 2024 20:06:31 -0800
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>,
Mark Rutland <mark.rutland@....com>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Al Viro <viro@...iv.linux.org.uk>, Michal Simek <monstr@...str.eu>
Subject: Re: [GIT PULL] ftrace: Fixes for v6.13
On Sat, 14 Dec 2024 at 19:11, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> That is, even though:
>
> TP_fast_assign(
> __entry->ipv6 = ptr_to_ipv6;
> )
>
> TP_printk("ipv6=%pI6", __entry->ipv6)
Again, you're not talking about the code that is being fixed.
I'm complaining about the mess that you try to fix in commit
ff54c8dc3f7a ("tracing: Fix trace output when pointer hash is
disabled"), which is that eldritch horror called
trace_check_vprintf().
You are describing something entirely different: the admittedly
similarly named test_event_printk(), called from the event init code.
I think trace_check_vprintf() should be removed entirely.
And I think test_event_printk() could probably be expanded to handle
at least some cases of '%s' (because, as you say, pointers to various
static allocations are fine for it).
And no, I don't know the code all that well, so maybe I'm overlooking
something, but trace_check_vprintf() really is a horror. And all your
arguments for it seem to be missing the mark and are actually
arguments for test_event_printk().
Linus
Powered by blists - more mailing lists