On Wed, Oct 23, 2024 at 08:18:35AM GMT, Lorenzo Stoakes wrote: > On Tue, Oct 22, 2024 at 05:53:00PM -0700, Shakeel Butt wrote: > > 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)? > > You can use either it will make no difference as both will get you to > current->mm which has to be shared. So I'd go with PIDFD_SELF for brevity > :) > > This series and the prerequisites I already added to process_madvise() > already provide support so with this in you can just use this for that. Thanks a lot, this is awesome. Is the plan for this series to go through mm-tree or through Christian?
