[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241214221212.38cc22c3@gandalf.local.home>
Date: Sat, 14 Dec 2024 22:12:12 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Linus Torvalds <torvalds@...ux-foundation.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 22:04:03 -0500
Steven Rostedt <rostedt@...dmis.org> wrote:
> With the check, instead it doesn't crash the kernel, but issues a nasty
> WARN_ON() (as it is a bug in the kernel) and then reads the value using
> safe mechanisms and injects into the trace "[UNSAFE-MEMORY]" by the pointer.
I will also point out that the check triggers even if the pointer is still
around (hasn't been freed). That is, it makes sure that the contents of the
pointer is in the ring buffer event that is being printed, or if a %s, it
is also OK to point to static strings (as the RCU trace points all do that).
That is, even though:
TP_fast_assign(
__entry->ipv6 = ptr_to_ipv6;
)
TP_printk("ipv6=%pI6", __entry->ipv6)
is buggy, and the check will report it immediately even if the contents of
that ptr_to_ipv6 hasn't been freed yet. But it is perfectly fine with:
TP_fast_assign(
memcpy(__entry->ipv6, ptr_to_ipv6, 16);
)
TP_printk("ipv6=%pI6", &__entry->ipv6)
As the content of the ipv6 lives in the ring buffer itself and will not be
freed at the time the event is printed.
-- Steve
Powered by blists - more mailing lists