From: Oleg Nesterov <oleg@redhat.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc: "mingo@kernel.org" <mingo@kernel.org>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"bp@alien8.de" <bp@alien8.de>,
"peterz@infradead.org" <peterz@infradead.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"axboe@kernel.dk" <axboe@kernel.dk>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"Mehta, Sohil" <sohil.mehta@intel.com>,
"broonie@kernel.org" <broonie@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"debug@rivosinc.com" <debug@rivosinc.com>
Subject: Re: [PATCH 5/6] x86/shstk: don't create the shadow stack for PF_USER_WORKERs
Date: Fri, 15 Aug 2025 14:17:03 +0200 [thread overview]
Message-ID: <20250815121702.GB11549@redhat.com> (raw)
In-Reply-To: <8818b456954644ce609e07d77a65714788ef9098.camel@intel.com>
On 08/14, Edgecombe, Rick P wrote:
>
> +Mark and Deepak
>
> On Thu, 2025-08-14 at 12:14 +0200, Oleg Nesterov wrote:
> > If a features_enabled(ARCH_SHSTK_SHSTK) userspace thread creates a
> > PF_USER_WORKER thread, shstk_alloc_thread_stack() allocates the shadow
> > stack for no reason, the new (kernel) thread will never return to usermode.
> >
> > Plus the current code doesn't even look correct, in this case fpu_clone()
> > won't call update_fpu_shstk().
...
> I agree we don't need to allocate a shadow stack in this case,
Great,
> but I'm not sure
> it is right to fully disable shadow stack in thread.features.
Why?
> First of all,
> disabling it from shstk_alloc_thread_stack() seems weird. It just handles
> allocating shadow stacks.
I agree in advance with any other change.
> Lastly, it doesn't seem there is any way to clone from IO uring today,
Not sure I understand... create_io_thread() ?
> How about just adding the 'minimal' condition to:
> if (clone_flags & CLONE_VFORK) {
> shstk->base = 0;
> shstk->size = 0;
> return 0;
> }
> ...then update all the comments where vfork is called out as the only case that
> does this?
but create_io_thread() and vhost_task_create() do not use CLONE_VFORK?
Oleg.
next prev parent reply other threads:[~2025-08-15 12:18 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-14 10:13 [PATCH 0/6] x86/fpu: don't abuse x86_task_fpu(PF_USER_WORKER) in .regset_get() paths Oleg Nesterov
2025-08-14 10:14 ` [PATCH 1/6] x86/fpu: change copy_xstate_to_uabi_buf() to accept fpstate + pkru instead of task_struct Oleg Nesterov
2025-08-14 16:46 ` Edgecombe, Rick P
2025-08-15 12:22 ` Oleg Nesterov
2025-08-14 10:14 ` [PATCH 2/6] x86/fpu: regset: introduce get_fpstate() helper Oleg Nesterov
2025-08-14 10:14 ` [PATCH 3/6] x86/fpu: fold sync_fpstate() into get_fpstate() Oleg Nesterov
2025-08-14 10:14 ` [PATCH 4/6] x86/shstk: add "task_struct *tsk" argument to reset_thread_features() Oleg Nesterov
2025-08-14 10:14 ` [PATCH 5/6] x86/shstk: don't create the shadow stack for PF_USER_WORKERs Oleg Nesterov
2025-08-14 17:03 ` Edgecombe, Rick P
2025-08-14 18:33 ` Mark Brown
2025-08-14 22:43 ` Edgecombe, Rick P
2025-08-15 11:44 ` Mark Brown
2025-08-15 19:11 ` Deepak Gupta
2025-08-18 17:27 ` Mark Brown
2025-08-19 17:41 ` Deepak Gupta
2025-08-15 13:01 ` Oleg Nesterov
2025-08-15 13:08 ` Oleg Nesterov
2025-08-15 15:28 ` Mark Brown
2025-08-15 15:43 ` Oleg Nesterov
2025-08-15 15:48 ` Mark Brown
2025-08-15 16:00 ` Oleg Nesterov
2025-08-15 17:08 ` Mark Brown
2025-08-15 12:17 ` Oleg Nesterov [this message]
2025-08-15 16:19 ` Edgecombe, Rick P
2025-08-15 16:54 ` Oleg Nesterov
2025-08-15 17:46 ` Edgecombe, Rick P
2025-08-15 19:13 ` Oleg Nesterov
2025-08-14 10:14 ` [PATCH 6/6] x86/fpu: change get_fpstate() to return &init_fpstate if PF_USER_WORKER Oleg Nesterov
2025-08-15 15:52 ` [PATCH 0/6] x86/fpu: don't abuse x86_task_fpu(PF_USER_WORKER) in .regset_get() paths Oleg Nesterov
2025-08-15 15:59 ` Dave Hansen
2025-08-15 16:02 ` Oleg Nesterov
2025-08-15 16:32 ` Sohil Mehta
2025-08-15 19:33 ` Oleg Nesterov
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=20250815121702.GB11549@redhat.com \
--to=oleg@redhat.com \
--cc=axboe@kernel.dk \
--cc=bp@alien8.de \
--cc=broonie@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=debug@rivosinc.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=sohil.mehta@intel.com \
--cc=tglx@linutronix.de \
--cc=x86@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.