[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgwy-p_zodT0JvkVkkd5MWy9NffC3jiDiczMMHPj1eQ9w@mail.gmail.com>
Date: Mon, 4 Mar 2024 13:50:13 -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>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Sachin Sant <sachinp@...ux.ibm.com>
Subject: Re: [GIT PULL] tracing: Prevent trace_marker being bigger than
unsigned short
On Mon, 4 Mar 2024 at 13:40, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> As I mentioned that the design is based on that the allocated buffer size is
> the string length rounded up to the word size, all I need to do is to make
> sure that there's a nul terminating byte within the last word of the
> allocated buffer. Then "%s" is all I need.
Please don't add pointless code that helps nothing.
> Would this work for you?
No. This code only adds debug code, and doesn't actually improve anything.
We *have* debug code already. Things like KASAN already find array
overruns, and your ex-tempore debug code adds zero actual value.
That, btw, is why your old stupid precision code was not only
triggering warnings, but was ACTIVELY DETRIMENTAL.
All that precision code could ever do was to potentially hide bugs if
the string wasn't NUL-terminated.
So no. I absolutely do NOT want you to write more code to hide bugs or
do half-arsed checking.
I want you to *simplify* the code, and put proper limits in place for strings.
I want to see the code that actually notices when somebody generates a
crazy string, and stops that garbage in its tracks.
What I do *not* want to see is more ad-hoc code that tries to deal
with the symptoms of you not having done so.
Linus
Powered by blists - more mailing lists