linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Deepak Gupta <debug@rivosinc.com>
To: Mark Brown <broonie@kernel.org>
Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
	"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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"axboe@kernel.dk" <axboe@kernel.dk>,
	"Mehta, Sohil" <sohil.mehta@intel.com>,
	"oleg@redhat.com" <oleg@redhat.com>,
	"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH 5/6] x86/shstk: don't create the shadow stack for PF_USER_WORKERs
Date: Tue, 19 Aug 2025 10:41:24 -0700	[thread overview]
Message-ID: <aKS3RHf9AC-nbdKo@debug.ba.rivosinc.com> (raw)
In-Reply-To: <2b1a11ea-7b1a-4d96-bf72-0e55227f7d21@sirena.org.uk>

On Mon, Aug 18, 2025 at 06:27:02PM +0100, Mark Brown wrote:
>On Fri, Aug 15, 2025 at 12:11:47PM -0700, Deepak Gupta wrote:
>> On Fri, Aug 15, 2025 at 12:44:14PM +0100, Mark Brown wrote:
>
>> > confirmation would be good but hopefully it's fine.  I've been holding
>> > back on sending a rebased version out since Deepak was going to help me
>> > get set up to test it on RISC-V.  Though I see now that the RISC-V code
>> > has vanished from -next (I guess due to fallout from the issues with the
>> > merge to Linus, it looks like there's almost nothing in the branch
>> > currently), not sure what the plan is there?
>
>> > Perhaps I should just send it out, but given the difficulty getting
>> > anyone to pay attention I was trying to avoid issues with missing
>> > updates for newly added RISC-V shadow stacks.
>
>> Yes I was trying to get that sorted as well. Because now I'll have to
>> rebase my changes to 6.17. So I wanted to make sure that it applies
>> cleanly. I suggest that you send it out because risc-v was left out
>> anyways. I'll apply your patch series on my risc-v shadow stack changes
>> (on top of 6.17) and will report back. It might be easier that way.
>
>> How does that sound?
>
>Sounds good.
>
>My main concern is that I don't want to end up needlessly holding off
>either series due to dependencies/cross tree issues - I remain
>(endlessly!) hopeful that the everyone's happy with the clone3() work at
>this point and it could get merged, but if RISC-V support is going in
>then it should support the new interface too.  Hopefully we can do
>something like apply this on a branch and then merge that into the
>RISC-V tree?

Yes they should make to upstream independent of each other. There are some
changes which I can adopt in my current set of changes (like change
`shstk_alloc_thread_stack` prototype). In your current patchsets
"fork: Add shadow stack support to clone3()" will need riscv support. Other
than that I see that support for `my_syscall2` for riscv arch will be needed.

If clone3 changes make in before riscv shadow stack changes, then its easy
I'll just add riscv specific changes pertaining to clone3 in my current
patchsets. 

If clone3 changes are later than riscv shadow stack changes, then I'll point
you to a branch from where you can pick riscv specific clone3 + shadow stack
changes.

If they both are going in together (may happen for 6.18 window), then we will
have to coordinate on which one applies first. So let's keep an eye on that.

If I push my branch somewhere on github (riscv shadow stack changes and then
clone3 changes on top of them), Is that fine?

-Deepak



  reply	other threads:[~2025-08-19 17:41 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 [this message]
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
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=aKS3RHf9AC-nbdKo@debug.ba.rivosinc.com \
    --to=debug@rivosinc.com \
    --cc=axboe@kernel.dk \
    --cc=bp@alien8.de \
    --cc=broonie@kernel.org \
    --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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).