On Thu, Oct 17, 2024 at 10:05:50PM GMT, Lorenzo Stoakes wrote:
It is useful to be able to utilise the pidfd mechanism to reference the current thread or process (from a userland point of view - thread group leader from the kernel's point of view).
Therefore introduce PIDFD_SELF_THREAD to refer to the current thread, and PIDFD_SELF_THREAD_GROUP to refer to the current thread group leader.
For convenience and to avoid confusion from userland's perspective we alias these:
PIDFD_SELF is an alias for PIDFD_SELF_THREAD - This is nearly always what the user will want to use, as they would find it surprising if for instance fd's were unshared()'d and they wanted to invoke pidfd_getfd() and that failed.
PIDFD_SELF_PROCESS is an alias for PIDFD_SELF_THREAD_GROUP - Most users have no concept of thread groups or what a thread group leader is, and from userland's perspective and nomenclature this is what userland considers to be a process.
Should users use PIDFD_SELF_PROCESS in process_madvise() for self madvise() (once the support is added)?
[...]
+static struct pid *pidfd_get_pid_self(unsigned int pidfd, unsigned int *flags) +{
- bool is_thread = pidfd == PIDFD_SELF_THREAD;
- enum pid_type type = is_thread ? PIDTYPE_PID : PIDTYPE_TGID;
- struct pid *pid = *task_pid_ptr(current, type);
- /* The caller expects an elevated reference count. */
- get_pid(pid);
Do you want this helper to work for scenarios where pid is used across context? Otherwise can't we get rid of this get and later put for self?
- return pid;
+}
Overall looks good to me.
Reviewed-by: Shakeel Butt shakeel.butt@linux.dev