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
