linux-kernel - Re: [GIT PULL] tracing: More updates for 6.13

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-=wgwQ5gDdHgN54n8hsm566x5bauNPsdZPXm6uOCFvPA1+Q@mail.gmail.com>
Date: Thu, 28 Nov 2024 11:55:34 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Masami Hiramatsu <mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, 
	Thomas Gleixner <tglx@...utronix.de>, Sebastian Andrzej Siewior <bigeasy@...utronix.de>, 
	Miguel Ojeda <ojeda@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>, rust-for-linux@...r.kernel.org, 
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] tracing: More updates for 6.13

On Wed, 27 Nov 2024 at 10:18, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> [
>   NOTE: The rust tracepoint code added hooks to the same macros that were
>   modified in this pull request. The merge has non-trivial conflicts. I
>   fixed it up in my "for-next" branch in the same repository. That branch
>   was a merge of this branch into the commit where you pulled the rust
>   tracepoint code.

I checked my resolution against yours, and I don't think your
resolution is right.

You didn't check 'cond' on regular rust tracepoints, and you didn't do
any locking on either kind.

I've pushed out my resolution, and hopefully rust people can actually
test it. I might just be full of it.

That said, I also think that the "__rust_do_trace_##name" inline
helper should just be renamed to "__trace_##name", and then the
regular trace_##name() helper could use that inside the
static_branch_unlikely() check. Because that seems to be the only real
thing the "rust" version wants - avoiding the static branch
infrastructure in favor of whatever rust infrastructure.

But hey, I do basic sanity build testing of the rust code, I don't
actually _know_ it. Again, I might be missing something.

            Linus