On Thu, Oct 17, 2024 at 10:05:50PM +0100, 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. > > Due to the refactoring of the central __pidfd_get_pid() function we can > implement this functionality centrally, providing the use of this sentinel > in most functionality which utilises pidfd's. > > We need to explicitly adjust kernel_waitid_prepare() to permit this (though > it wouldn't really make sense to use this there, we provide the ability for > consistency). > > We explicitly disallow use of this in setns(), which would otherwise have > required explicit custom handling, as it doesn't make sense to set the > current calling thread to join the namespace of itself. > > As the callers of pidfd_get_pid() expect an increased reference count on > the pid we do so in the self case, reducing churn and avoiding any breakage > from existing logic which decrements this reference count. > > This change implicitly provides PIDFD_SELF_* support in the waitid(P_PIDFS, > ...), process_madvise(), process_mrelease(), pidfd_send_signal(), and > pidfd_getfd() system calls. > > Things such as polling a pidfs and general fd operations are not supported, > this strictly provides the sentinel for APIs which explicitly accept a > pidfd. > We need a: Suggested-by: Pedro Falcato <pedro.falcato@xxxxxxxxx> here, will add if respin, otherwise could you add Christian? My apologies Pedro, this was wholly an oversight and my mistake! > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
