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

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 27 Aug 2026 10:45:29 +0100
Bradley Morgan <brads@mainlining.org> wrote:

> >I usually don't think about adding comments, but yes, that's a good
> >suggestion.
> >  
> >> 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  
> >> to be added to the description, keep the description length the same as
> >> 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.

> >> 
> >> Instead of doing 3 paragraths about a one liner, we could do a small two
> >> 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.

The added comment to the code is fine though.

Thanks,

-- Steve