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] [day] [month] [year] [list]

Message-ID: <CAH5fLgg53QovLfA-C+j+E0FeQ8-gQgG76ZbeCN4-qEJ5KPOQEg@mail.gmail.com>
Date: Fri, 29 Nov 2024 10:36:30 +0100
From: Alice Ryhl <aliceryhl@...gle.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Steven Rostedt <rostedt@...dmis.org>, 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>, rust-for-linux@...r.kernel.org, 
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] tracing: More updates for 6.13

On Thu, Nov 28, 2024 at 8:55 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> 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.

The Rust parts look reasonable to me, thanks!

Alice