On Wed, Oct 23, 2024 at 10:18:28AM -0700, Shakeel Butt wrote:
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?
Thanks!
I am assuming this will go through Christian's tree as entirely within the pidfd realm :)
Christian - I am assuming this is your expectation too right?
I cc'd linux-mm more for convenience as obviously am hoping to use this for an mm thing myself.