Re: [PATCH v2] tracing/user_events: Clear copied tracing state before fork duplication

On 27 August 2026 13:15:31 BST, Steven Rostedt [off-list ref] wrote:

On Thu, 27 Aug 2026 10:45:29 +0100
Bradley Morgan [off-list ref] wrote:

quoted

quoted

I usually don't think about adding comments, but yes, that's a good
suggestion.
 

quoted

Maybe you could add this to your memories

"The description length should be about the same as the change being
added,unless there is a splat, or something else like a table which  

needs  

quoted

to be added to the description, keep the description length the same

as

quoted

quoted

quoted

thepatch size, e.g:

No that is not correct. In fact, some of my longest change logs are
one-liners and my big changes are small descriptions.

A one-line can be extremely subtle and require a deep description of the
problem. Big changes may be "Implement this feature" with a description of
the feature that is much shorter than the code used to create it.

Hmm, could be right, my memory isn't perfect, don't worry.

quoted

quoted

quoted

Instead of doing 3 paragraths about a one liner, we could do a small

two

quoted

quoted

quoted

or more line description describing:

What causes the issue?
Why is it bad?
How did you fix it?"  

Sounds like a good practical advice, thanks. Yet in the present case,
since there is a security issue with the UAF, I felt that it was
important to explain where it came from instead of something very
short along the lines ("fixing a UAF"), hence the couple of paragraphs
and the KASAN output.
 

umm, you could include a ASCII table or something, that signifies the

bug?

I think the change log is fine and doesn't need to be changed.

Yeah, I do too.

The added comment to the code is fine though.

:)

Thanks,

-- Steve

--- Thanks!

https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/ (local)