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

[Bradley Morgan]

On 27 August 2026 13:15:31 BST, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>On Thu, 27 Aug 2026 10:45:29 +0100
>Bradley Morgan <brads@xxxxxxxxxxxxxx> 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.
>

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

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

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@xxxxxxxxx/