Re: [PATCH] tracing/user_events: Fail fork when event state duplication fails

On Tue, 6 Oct 2026 08:01:14 -0400
Jeff Barnes [off-list ref] 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