All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Aleksa Sarai <cyphar@cyphar.com>,
	Tycho Andersen <tandersen@netflix.com>,
	Daan De Meyer <daan.j.demeyer@gmail.com>,
	Tejun Heo <tj@kernel.org>,
	stable@vger.kernel.org
Subject: Re: [PATCH] pidfd: prevent creation of pidfds for kthreads
Date: Wed, 31 Jul 2024 16:51:33 +0200	[thread overview]
Message-ID: <20240731145132.GC16718@redhat.com> (raw)
In-Reply-To: <20240731-gleis-mehreinnahmen-6bbadd128383@brauner>

On 07/31, Christian Brauner wrote:
>
> It's currently possible to create pidfds for kthreads but it is unclear
> what that is supposed to mean. Until we have use-cases for it and we
> figured out what behavior we want block the creation of pidfds for
> kthreads.

Hmm... could you explain your concerns? Why do you think we should disallow
pidfd_open(pid-of-kthread) ?

> @@ -2403,6 +2416,12 @@ __latent_entropy struct task_struct *copy_process(
>  	if (clone_flags & CLONE_PIDFD) {
>  		int flags = (clone_flags & CLONE_THREAD) ? PIDFD_THREAD : 0;
>  
> +		/* Don't create pidfds for kernel threads for now. */
> +		if (args->kthread) {
> +			retval = -EINVAL;
> +			goto bad_fork_free_pid;

Do we really need this check? Userspace can't use args->kthread != NULL,
the kernel users should not use CLONE_PIDFD.

Oleg.


  reply	other threads:[~2024-07-31 14:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-31 10:01 [PATCH] pidfd: prevent creation of pidfds for kthreads Christian Brauner
2024-07-31 14:51 ` Oleg Nesterov [this message]
2024-08-01  6:58   ` Christian Brauner
2024-08-01  8:01     ` Oleg Nesterov
2024-08-01 13:48       ` Christian Brauner
2024-08-01 13:59         ` Oleg Nesterov
2024-08-18  3:58 ` Eric Biggers
2024-08-19  8:41   ` Christian Brauner
2024-08-20 19:34     ` Eric Biggers
2024-08-21  7:41       ` Christian Brauner
2024-08-21  7:47         ` Daan De Meyer
2024-08-23  5:23     ` Linux regression tracking (Thorsten Leemhuis)
2024-08-23  6:12       ` Greg KH

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=20240731145132.GC16718@redhat.com \
    --to=oleg@redhat.com \
    --cc=brauner@kernel.org \
    --cc=cyphar@cyphar.com \
    --cc=daan.j.demeyer@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tandersen@netflix.com \
    --cc=tj@kernel.org \
    /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.