From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Christian Brauner <christian@brauner.io>,
Shuah Khan <shuah@kernel.org>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Suren Baghdasaryan <surenb@google.com>,
Vlastimil Babka <vbabka@suse.cz>,
pedro.falcato@gmail.com, linux-kselftest@vger.kernel.org,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
Oliver Sang <oliver.sang@intel.com>,
John Hubbard <jhubbard@nvidia.com>
Subject: Re: [PATCH v4 2/4] pidfd: add PIDFD_SELF_* sentinels to refer to own thread/process
Date: Wed, 23 Oct 2024 08:18:35 +0100 [thread overview]
Message-ID: <f6114921-d3c7-4092-b503-09f99d98ad83@lucifer.local> (raw)
In-Reply-To: <fhy36lhgeedrdwoubuuxarownhji2k4avcherjnedtid35yael@jokjnyb6i66b>
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.
>
> >
> [...]
> >
> > +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?
Yeah I hate doing this but it's to keep things as generic as possible and
to ensure that no user of this logic accidentally drops the reference count
unintentionally + to reduce churn.
I think doing it this way is better than trying to special case the put,
and in any case if you did the 'old' way of referencing yourself you'd have
ended up doing this anyway so it's at least no delta!
>
> > + return pid;
> > +}
> > +
>
> Overall looks good to me.
>
> Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev>
Thanks!
next prev parent reply other threads:[~2024-10-23 7:18 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-17 21:05 [PATCH v4 0/4] introduce PIDFD_SELF* sentinels Lorenzo Stoakes
2024-10-17 21:05 ` [PATCH v4 1/4] pidfd: extend pidfd_get_pid() and de-duplicate pid lookup Lorenzo Stoakes
2024-10-23 0:20 ` Shakeel Butt
2024-10-17 21:05 ` [PATCH v4 2/4] pidfd: add PIDFD_SELF_* sentinels to refer to own thread/process Lorenzo Stoakes
2024-10-21 8:11 ` Lorenzo Stoakes
2024-10-23 0:53 ` Shakeel Butt
2024-10-23 7:18 ` Lorenzo Stoakes [this message]
2024-10-23 17:18 ` Shakeel Butt
2024-10-23 17:24 ` Lorenzo Stoakes
2024-10-17 21:05 ` [PATCH v4 3/4] selftests: pidfd: add pidfd.h UAPI wrapper Lorenzo Stoakes
2024-10-17 21:45 ` John Hubbard
2024-10-17 22:11 ` Shuah Khan
2024-10-17 22:22 ` John Hubbard
2024-10-18 6:49 ` Lorenzo Stoakes
2024-10-18 23:55 ` John Hubbard
2024-10-17 21:05 ` [PATCH v4 4/4] selftests: pidfd: add tests for PIDFD_SELF_* Lorenzo Stoakes
2024-10-25 8:10 ` kernel test robot
2024-10-25 8:48 ` Lorenzo Stoakes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f6114921-d3c7-4092-b503-09f99d98ad83@lucifer.local \
--to=lorenzo.stoakes@oracle.com \
--cc=Liam.Howlett@oracle.com \
--cc=christian@brauner.io \
--cc=jhubbard@nvidia.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=oliver.sang@intel.com \
--cc=pedro.falcato@gmail.com \
--cc=shakeel.butt@linux.dev \
--cc=shuah@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox