From: Tycho Andersen <tycho@tycho.pizza>
To: Florian Weimer <fweimer@redhat.com>
Cc: Christian Brauner <brauner@kernel.org>,
Oleg Nesterov <oleg@redhat.com>,
"Eric W . Biederman" <ebiederm@xmission.com>,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
Tycho Andersen <tandersen@netflix.com>,
mathieu.desnoyers@efficios.com
Subject: Re: [RFC 1/3] pidfd: allow pidfd_open() on non-thread-group leaders
Date: Thu, 30 Nov 2023 11:54:00 -0700 [thread overview]
Message-ID: <ZWjaSAhG9KI2i9NK@tycho.pizza> (raw)
In-Reply-To: <874jh3t7e9.fsf@oldenburg.str.redhat.com>
On Thu, Nov 30, 2023 at 07:37:02PM +0100, Florian Weimer wrote:
> * Tycho Andersen:
>
> > From: Tycho Andersen <tandersen@netflix.com>
> >
> > We are using the pidfd family of syscalls with the seccomp userspace
> > notifier. When some thread triggers a seccomp notification, we want to do
> > some things to its context (munge fd tables via pidfd_getfd(), maybe write
> > to its memory, etc.). However, threads created with ~CLONE_FILES or
> > ~CLONE_VM mean that we can't use the pidfd family of syscalls for this
> > purpose, since their fd table or mm are distinct from the thread group
> > leader's. In this patch, we relax this restriction for pidfd_open().
>
> Does this mean that pidfd_getfd cannot currently be used to get
> descriptors for a TID if that TID doesn't happen to share its descriptor
> set with the thread group leader?
Correct, that's what I'm trying to solve.
> I'd like to offer a userspace API which allows safe stashing of
> unreachable file descriptors on a service thread.
By "safe" here do you mean not accessible via pidfd_getfd()?
Tycho
next prev parent reply other threads:[~2023-11-30 18:54 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-30 16:39 [RFC 1/3] pidfd: allow pidfd_open() on non-thread-group leaders Tycho Andersen
2023-11-30 16:39 ` [RFC 2/3] selftests/pidfd: add non-thread-group leader tests Tycho Andersen
2023-11-30 16:39 ` [RFC 3/3] clone: allow CLONE_THREAD | CLONE_PIDFD together Tycho Andersen
2023-11-30 17:39 ` [RFC 1/3] pidfd: allow pidfd_open() on non-thread-group leaders Oleg Nesterov
2023-11-30 17:56 ` Tycho Andersen
2023-12-01 16:31 ` Tycho Andersen
2023-12-07 17:57 ` Christian Brauner
2023-12-07 21:25 ` Christian Brauner
2023-12-08 20:04 ` Tycho Andersen
2023-11-30 18:37 ` Florian Weimer
2023-11-30 18:54 ` Tycho Andersen [this message]
2023-11-30 19:00 ` Mathieu Desnoyers
2023-11-30 19:17 ` Tycho Andersen
2023-11-30 19:43 ` Florian Weimer
2023-12-06 15:27 ` Tycho Andersen
2023-12-07 22:58 ` Christian Brauner
2023-12-08 3:16 ` Jens Axboe
2023-12-08 13:15 ` Florian Weimer
2023-12-08 13:48 ` Christian Brauner
2023-12-08 13:58 ` Florian Weimer
2023-12-07 17:21 ` Christian Brauner
2023-12-07 17:52 ` Tycho Andersen
2023-12-08 17:47 ` Jan Kara
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=ZWjaSAhG9KI2i9NK@tycho.pizza \
--to=tycho@tycho.pizza \
--cc=brauner@kernel.org \
--cc=ebiederm@xmission.com \
--cc=fweimer@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=oleg@redhat.com \
--cc=tandersen@netflix.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.