All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sohil Mehta <sohil.mehta@intel.com>
To: Oleg Nesterov <oleg@redhat.com>, Dave Hansen <dave.hansen@intel.com>
Cc: Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
	Jens Axboe <axboe@kernel.dk>,
	Peter Zijlstra <peterz@infradead.org>,
	Rick Edgecombe <rick.p.edgecombe@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	<linux-kernel@vger.kernel.org>, <x86@kernel.org>,
	Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH 0/6] x86/fpu: don't abuse x86_task_fpu(PF_USER_WORKER) in .regset_get() paths
Date: Fri, 15 Aug 2025 09:32:00 -0700	[thread overview]
Message-ID: <f8aaa8a3-e4aa-4958-a147-9a40385ebd8d@intel.com> (raw)
In-Reply-To: <20250815160244.GI11549@redhat.com>

On 8/15/2025 9:02 AM, Oleg Nesterov wrote:
>>> Dave, Sohil, what do you think?

Thank you for doing this series.

I think it would be useful to categorize the impact of the "abuse" in
the cover letter. Is it going to cause kernel crashes, userspace crashes
or just incorrect reporting?

Are there any "must do" fixes that need to be backported in comparison
with the "good to have" optimizations? I am wondering if it might be
possible to structure the series that way to make the separation clear.


> I agree about the cover letter, but what else do you think the changelog
> in 1/6 could say? ;)
> 

For folks like me who are barely familiar with the FPU code, some
additional context or reasoning would be surely be useful.

For example, I don't know why PKRU needs to be passed separately. I know
there is some history there but a line or two in the changelog might help.



  reply	other threads:[~2025-08-15 16:32 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
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 [this message]
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=f8aaa8a3-e4aa-4958-a147-9a40385ebd8d@intel.com \
    --to=sohil.mehta@intel.com \
    --cc=axboe@kernel.dk \
    --cc=bp@alien8.de \
    --cc=broonie@kernel.org \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rick.p.edgecombe@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.