Re: [GIT PULL] tracing: More updates for 6.13

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 28 Nov 2024 11:55:34 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:


> 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.

Bah, you're right. The cond is only needed if they utilize it, which
I'm not sure they do, but the locking is definitely needed. My brain
was off when doing the merge conflict. I was thinking more of "what
makes this compile" than how it actually works.

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

Looks better than what I had. I'll kick my tests on it just as a sanity
check.

> 
> 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.

Hmm, I think that could be done.

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

I need to spend some time understanding the rust code, so I can at least
review it better.

-- Steve