On Oct 6 2026, at 8:38 am, Steven Rostedt <[email protected]> wrote:
> On Tue, 6 Oct 2026 08:01:14 -0400
> Jeff Barnes <[email protected]> wrote:
>
>> Yes, that was intentional. My concern with allowing fork() to succeed
>> after removing the child's user_events state is that the allocation
>> failure then becomes a silent loss of inherited tracing state.
>>
>> The enable word is the userspace-visible indication that an event is
>> enabled. If the child loses its inherited enablers, later enable and
>> disable changes will no longer be reflected in that child. Removing the
>> state fixes the stale-value inconsistency, but userspace has no
>> indication from fork() that the child is no longer following the
>> inherited tracing state.
>>
>> I also think there is a potential security implication here. If
>> user_events are being used for tracing or auditing, an allocation
>> failure could result in a successfully created child silently no longer
>> following subsequent enablement changes. I don't want to characterize
>> that as a security vulnerability without a demonstrated security
>> boundary, but silently losing that state seems undesirable for auditing
>> in particular.
>>
>> That is why I favored returning -ENOMEM: either the child is created
>> with the inherited user_events state intact, or the failure is visible
>> to userspace and the fork is unwound.
>>
>> I agree that uprobes provides a useful comparison. If you think
>> user_events should likewise be best-effort across fork, then removing
>> the state on duplication failure would address the inconsistency without
>> introducing the new fork() failure path.
>
> Question, to use user events the application needs to be involved,
> correct? That is, there's code in the application specific for
> user_events, as supposed to uprobes that can attach to any application.
>
> Thus, it makes sense for uprobes to only warn on failure. Why should a
> task fail to fork if something attaches a uprobe on it and it causes
> issues.
>
> Now if user_events is driven by the application that has them, then
> yes, it makes sense for fork() to fail if the user_event it created
> fails processing inside the fork(). If the user application is
> expecting something, then if it fails it should know about it.
>
> But this is only if user_events is driven by the application doing the
> fork().
>
> -- Steve
>
Yes, that's correct. user_events registration is initiated by the
application through the user_events interface, rather than being
attached externally to an arbitrary application like an uprobe.
So in this case the state being duplicated during fork() is state that
the application itself established. That's why I think propagating the
allocation failure back through fork() is preferable to silently
allowing the child to lose that state.
Thanks, Jeff
