From: Bradley Morgan <brads@mainlining.org>
To: "Jérémy Jean" <jeremy.jean@oss.cyber.gouv.fr>,
"Steven Rostedt" <rostedt@goodmis.org>
Cc: mhiramat@kernel.org, mathieu.desnoyers@efficios.com,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v2] tracing/user_events: Clear copied tracing state before fork duplication
Date: Thu, 27 Aug 2026 13:29:20 +0100 [thread overview]
Message-ID: <CE51AB37-6584-4001-9375-24AA00C8B79D@mainlining.org> (raw)
In-Reply-To: <3beb0339407a35c0b995856eae74d870@oss.cyber.gouv.fr>
On 27 August 2026 13:27:44 BST, "Jérémy Jean"
<jeremy.jean@oss.cyber.gouv.fr> wrote:
>On 2026-08-27 14:19, Steven Rostedt wrote:
>> On Thu, 27 Aug 2026 13:09:44 +0100
>> Bradley Morgan <brads@mainlining.org> wrote:
>>
>>> >> @@ -865,9 +865,12 @@ void user_event_mm_remove(struct task_struct
>*t)
>>> >>
>>> >> void user_event_mm_dup(struct task_struct *t, struct user_event_mm
>>> >*old_mm)
>>> >> {
>>> >> - struct user_event_mm *mm = user_event_mm_alloc(t);
>>> >> + struct user_event_mm *mm;
>>> >
>>> >Why this change?
>>> >
>>> >> struct user_event_enabler *enabler;
>>> >>
>>> >> + t->user_event_mm = NULL;
>>> >> + mm = user_event_mm_alloc(t);
>>> >
>>> >I don't see why you moved the mm assignment down here. The
>>> >t->user_event_mm
>>> >is not used in user_event_mm_alloc().
>>>
>>> Uff, not wrong, I must be dummy dumb dumb, well, I base my reviews off
>>>
>>> Does this fix the bug? And is this a small fix?
>>>
>>
>> The bug is fixed because it needs to NULL out that value. I asked from
>v1
>> to move that change to this function. But this function only needs to
>add
>> that line before the return. It doesn't need to modify anything else in
>> that function.
>>
>> That is, something like this:
>>
>> diff --git a/kernel/trace/trace_events_user.c
>b/kernel/trace/trace_events_user.c
>> index 8c82ecb735f4..6b89d225b189 100644
>> --- a/kernel/trace/trace_events_user.c
>> +++ b/kernel/trace/trace_events_user.c
>> @@ -868,6 +868,9 @@ void user_event_mm_dup(struct task_struct *t, struct
>user_event_mm *old_mm)
>> struct user_event_mm *mm = user_event_mm_alloc(t);
>> struct user_event_enabler *enabler;
>>
>> + /* On failure, do not free parent's copy */
>> + t->user_event_mm = NULL;
>> +
>> if (!mm)
>> return;
>>
>>
>> -- Steve
>
>Hello Steve,
>
>Thanks for this. I thought that my previous version was okay
>so that it was not required to read the details of
>user_event_mm_alloc() to get convinced whether user_event_mm is
>accessed or not, but it's true that in the end, this is not
>required. Your fix is simpler. Do you want me to send a v3
>with that simplification and the same changelog as in the v2?
>
>Regards,
>Jérémy
I wouldn't mind, add my tag, I review differently from Steven, so Steven
may not be happy at me :(
I review on
1: does this do what it's intended
2: does it fix X?
3: Any comments, any new functions used instead, any way to get the line count shorter?
And others, I apologise if I'm wrong. I just review in a different style.
--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/
next prev parent reply other threads:[~2026-08-27 12:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 21:44 [PATCH v2] tracing/user_events: Clear copied tracing state before fork duplication Jérémy Jean
2026-08-26 22:37 ` Bradley Morgan
2026-08-27 7:15 ` Jérémy Jean
2026-08-27 9:45 ` Bradley Morgan
2026-08-27 12:15 ` Steven Rostedt
2026-08-27 12:17 ` Bradley Morgan
2026-08-27 12:08 ` Steven Rostedt
2026-08-27 12:09 ` Bradley Morgan
2026-08-27 12:19 ` Steven Rostedt
2026-08-27 12:24 ` Bradley Morgan
2026-08-27 12:27 ` Jérémy Jean
2026-08-27 12:29 ` Bradley Morgan [this message]
2026-08-27 12:43 ` Steven Rostedt
2026-08-27 12:44 ` Bradley Morgan
2026-08-27 12:42 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CE51AB37-6584-4001-9375-24AA00C8B79D@mainlining.org \
--to=brads@mainlining.org \
--cc=jeremy.jean@oss.cyber.gouv.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox