linux-kernel - Re: [PATCH 1/3] ring-buffer: Add uname to match criteria for persistent ring buffer

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]

Message-ID: <CAHk-=whWfmZbwRmySSpOyYEZJgcKG3d-qheYidnwu+b+rk6THg@mail.gmail.com>
Date: Tue, 17 Dec 2024 14:24:08 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org, 
	Masami Hiramatsu <mhiramat@...nel.org>, Mark Rutland <mark.rutland@....com>, 
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	stable@...r.kernel.org
Subject: Re: [PATCH 1/3] ring-buffer: Add uname to match criteria for
 persistent ring buffer

On Tue, 17 Dec 2024 at 11:43, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> But this will be future work and not something for this merge window, as
> it's more of a feature. The only fix is to add that print_field() code, and
> the patch series that removes trace_check_vprintf() (which fixes a
> different bug).

Side note: I've also been looking at the core vsnprintf() code to see
if it could be cleanly extended to have callers give more control over
it. Some kind of callback mechanism for the pointer handling so that
there is *not* any need for crazy hackery.

That needs some basic cleanups I want to do and that I'm playing with,
but even with some of that code cleaned up it looks a bit nasty.

I really don't want to expose too much of the internals to the
outside, and vsnprintf() is actually fairly performance-critical, and
indirect calls have become so expensive that I really don't want to
introduce function pointers in there.

But I'll try to see if some more cleanups would make it at least
possible to have a separate version. That said, we already have the
disgusting "binary printf" code, used by bpf and tracing, and I'd hate
to introduce a *third* interface, particularly since the binary printf
code is already doing things wrong (it puts things into a "word
array", but instead of using a single word for char/short like the
normal C varargs code does, it packs them at actual byte/word
boundaries and adds padding etc).

So just looking at that code, I'm not hugely excited about adding yet
more copies of this and new interfaces in this area.

(Aside: are those binary buffers actually exported to user space (that
"u32 *bin_buf, size_t size" thing), or could we fix the binary printf
code to really use a whole word for char/short values? The difference
between '%hhd' and '%d' should be how it's printed out, not how the
data is accessed)

               Linus