mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	michael.christie@oracle.com, Tejun Heo <tj@kernel.org>,
	Luca Boccassi <bluca@debian.org>, Jens Axboe <axboe@fb.com>,
	axboe@kernel.dk
Subject: Re: [PATCH] KVM: x86: switch hugepage recovery thread to vhost_task
Date: Thu, 19 Dec 2024 16:31:40 -0700	[thread overview]
Message-ID: <Z2Ss3ALr5QgHo4UP@kbusch-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <6b0c90e6-6b38-4ff3-8778-1857cd66c206@redhat.com>

On Thu, Dec 19, 2024 at 11:57:40PM +0100, Paolo Bonzini wrote:
> It could be as simple as this on the kernel side: [adding Jens for
> a first look]

Cc'ing his @kernel email; first message:

	https://lore.kernel.org/linux-kernel/20241108130737.126567-1-pbonzini@redhat.com/
 
> =============== 8< ===========
> From: Paolo Bonzini <pbonzini@redhat.com>
> Subject: [PATCH] fs: proc: mark user and I/O workers as "kernel threads"
> 
> A Rust library called "minijail" is looking at procfs to check if
> the current task has multiple threads, and to prevent fork() if it
> does.  This is because fork() is in general ill-advised in
> multi-threaded programs, for example if another thread might have
> taken locks.
> 
> However, this attempt falls afoul of kernel threads that are children
> of the user process that they serve.  These are not a problem when
> forking, but they are still present in procfs.  The library should
> discard them, but there is currently no way for userspace to detect
> PF_USER_WORKER or PF_IO_WORKER threads.
> 
> The closest is the "Kthread" key in /proc/PID/task/TID/status.  Extend
> it instead of introducing another keyl tasks that are marked with
> PF_USER_WORKER or PF_IO_WORKER are not kthreads, but they are close
> enough for basically all intents and purposes.

Yes, this looks good to me. But I also would have thought the original
patch was safe too :). Hopefully nothing depends on the current value
for these... there is often something making it difficult to have nice
things.

> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> 
> diff --git a/fs/proc/array.c b/fs/proc/array.c
> index 34a47fb0c57f..f702fb50c8ef 100644
> --- a/fs/proc/array.c
> +++ b/fs/proc/array.c
> @@ -221,7 +221,7 @@ static inline void task_state(struct seq_file *m, struct pid_namespace *ns,
>  #endif
>  	seq_putc(m, '\n');
> -	seq_printf(m, "Kthread:\t%c\n", p->flags & PF_KTHREAD ? '1' : '0');
> +	seq_printf(m, "Kthread:\t%c\n", p->flags & (PF_KTHREAD | PF_USER_WORKER | PF_IO_WORKER) ? '1' : '0');
>  }
>  void render_sigset_t(struct seq_file *m, const char *header,UBLK_U_IO_REGISTER_ZC_RING

  reply	other threads:[~2024-12-19 23:31 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-08 13:07 Paolo Bonzini
2024-11-08 16:53 ` Tejun Heo
2024-11-09  0:23   ` Luca Boccassi
2024-11-13 23:56 ` Sean Christopherson
2024-11-14 12:02   ` Paolo Bonzini
2024-11-14 15:38     ` Sean Christopherson
2024-11-15 16:59 ` Michal Koutný
2024-11-18 12:42   ` Paolo Bonzini
2024-11-25  9:01     ` Michal Koutný
2024-11-25 11:22       ` Paolo Bonzini
2024-12-19 17:32 ` Keith Busch
2024-12-19 17:42   ` Paolo Bonzini
2024-12-19 18:08     ` Keith Busch
2024-12-19 20:30       ` Paolo Bonzini
2024-12-19 22:23         ` Keith Busch
2024-12-19 22:57           ` Paolo Bonzini
2024-12-19 23:31             ` Keith Busch [this message]
2025-01-13 15:35         ` Keith Busch
2025-01-14 18:10           ` Paolo Bonzini
2025-01-15  3:06             ` Sean Christopherson
2025-01-15 16:51               ` Keith Busch
2025-01-15 17:10                 ` Paolo Bonzini
2025-01-15 19:03                   ` Keith Busch
2025-01-22 11:38                     ` Alyssa Ross
2025-01-22 14:56                       ` Keith Busch
2025-01-22 22:32                         ` Alyssa Ross

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=Z2Ss3ALr5QgHo4UP@kbusch-mbp.dhcp.thefacebook.com \
    --to=kbusch@kernel.org \
    --cc=axboe@fb.com \
    --cc=axboe@kernel.dk \
    --cc=bluca@debian.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.christie@oracle.com \
    --cc=pbonzini@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®