On Wed, Jun 10, 2026, at 8:29 AM, Li Chen wrote: > Hi John, > > [...] > > Thanks, this helped a lot. I looked at FreeBSD/OpenBSD/XNU after your > note. FreeBSD has P_INEXEC, OpenBSD has PS_INEXEC, and XNU seems even > closer with P_LINTRANSIT, described as "process in exec or in creation". > Linux does not seem to have a single equivalent today: current->in_execve > is only an LSM hint, while the real synchronization is spread across > exec_update_lock, cred_guard_mutex, and the exec path.
Great! Glad to hear my suggestion (and the patch too I linked in the other email, I hope?) was useful. > I am switching my local WIP from the two-fd builder model to one fd, > closer to Christian's sketch: > > fd = pidfd_open(0, PIDFD_EMPTY); > pidfd_config(fd, ...); > pidfd_spawn_run(fd, ...); Glad to hear it is also one-fd now. > In my current local version, I still use copy_process(), so the fd points > at a real task_struct/pid that is not woken until run. So this is an interesting thing to think about. My hunch is that `copy_process` is, at least in the longer term, still doing too much! In particular, `struct kernel_clone_args` has many degrees of freedom, and might also make assumptions about preserving more of the parent process than is needed in this case. This is a bit tangential, but one thing I have thought about is having "null namespaces". I think the current (i.e. existing clone API) default of "share with parent process" is a poor security practice (more privileges, i.e. sharing, should always be opt-in). But the opposite default of "unshare everything" is expensive since creating new namespaces is non-free. The goal of the null namespaces would be a cheap way of creating a more isolated and unprivileged process — and "cheap" here is literal: a null pointer in `nsproxy`, no allocation, no namespace object, no ID. This null state would be what `pidfd_open(0, PIDFD_EMPTY)` (using your example above, or really whatever the first step is) hands back. Then, from that maximally cheap and unprivileged initial state, the `pidfd_config(fd, ...);` calls (plural important, I think!) would opt into either sharing or unsharing namespaces between the child and parent as the parent sees fit. The larger point here is that insofar as there are not good defaults for things, there is pressure, whether in step 1 or step 2, to make larger everything-at-once configuration. But when we think a bit outside the box to create the good defaults where they didn't previously exist, we can end up in a situation where a minimal initial blank unstarted process, and the builder pattern to initialize it, are more "natural". > Following > Christian's point that existing APIs can handle this not-yet-running case > with ESRCH, I currently make ordinary pidfd operations that need a real > started process return -ESRCH before start. Also glad to hear. > I am not sure yet whether Linux should grow a general exec/creation > transition state like that, or whether a narrower future-process > lifecycle is enough for this API. I will think more about that when > working on the pristine process version. Sounds good, as I think you can guess, my preference is for "yes", but I agree we can see what you end up with in the next patchset and make more informed decisions based on that. Cheers, John
