All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Vladimir Murzin <vladimir.murzin@arm.com>,
	Arnd Bergmann <arnd@arndb.de>, Marc Zyngier <maz@kernel.org>,
	Linus Walleij <linusw@kernel.org>,
	linux-kernel@vger.kernel.org, Mostafa Saleh <smostafa@google.com>,
	David Hildenbrand <david@kernel.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Oliver Upton <oupton@kernel.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 15/21] arm64: entry: Point SP_EL0 at the overflow stack
Date: Mon, 21 Sep 2026 16:56:47 +0100	[thread overview]
Message-ID: <arFTvxg2FJQUV7qt@arm.com> (raw)
In-Reply-To: <20260918161407.2300-16-will@kernel.org>

On Fri, Sep 18, 2026 at 05:13:59PM +0100, Will Deacon wrote:
>  static void __init set_boot_cpu_offset(void)
>  {
> -	asm volatile("msr tpidr_el1, %0"
> -			:: "r" (per_cpu_offset(0)) : "memory");
> +	u64 ovf_sp = (u64)raw_cpu_ptr(overflow_stack) + OVERFLOW_STACK_SIZE;

raw_cpu_ptr() is using tpidr_el1 and we haven't initialised it yet.
Actually, I think we get away with it because in head.S we initialise it
to 0 (__per_cpu_offsets[0] is still zero at that point for the boot CPU).

> +
> +	asm volatile(
> +	"	msr	tpidr_el1, %1\n"
> +	"	add	%0, %0, %1\n"
> +	"	msr	sp_el0, %0" /* Update the overflow stack pointer */
> +	: "+r" (ovf_sp)
> +	: "r" (per_cpu_offset(0))
> +	: "memory");

Even if this is intentional and we rely in TPIDR_EL1 to be 0, it feels
weird to add the offset to raw_cpu_ptr().

Could we just do (untested):

	unsigned long ovf_sp = (unsigned long)per_cpu_ptr(overflow_stack, 0) +
		OVERFLOW_STACK_SIZE;

	asm volatile(
	"	msr	tpidr_el1, %0\n"
	"	msr	sp_el0, %1"
	:
	: "r" (per_cpu_offset(0)), "r" (ovf_sp)
	: "memory");

with no further arithmetics in asm.

-- 
Catalin


  reply	other threads:[~2026-09-21 15:57 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-18 16:13 [PATCH v2 00/21] arm64: Move overflow sp into SP_EL1 and kernel sp into SP_EL0 Will Deacon
2026-09-18 16:13 ` [PATCH v2 01/21] arm64: entry: Defer setting of TPIDRRO_EL0 until exit to userspace Will Deacon
2026-09-30 20:47   ` Linus Walleij
2026-09-18 16:13 ` [PATCH v2 02/21] arm64: entry: Only check for stack overflow on exceptions from EL1 Will Deacon
2026-09-30 20:50   ` Linus Walleij
2026-10-08  6:54   ` Jinjie Ruan
2026-09-18 16:13 ` [PATCH v2 03/21] arm64: stackprotector: Temporarily disable per-task stackprotector Will Deacon
2026-09-30 21:01   ` Linus Walleij
2026-09-18 16:13 ` [PATCH v2 04/21] arm64: bpf: Add support for generating reads of TPIDRRO_EL0 Will Deacon
2026-09-30 20:53   ` Linus Walleij
2026-10-08  7:07   ` Jinjie Ruan
2026-09-18 16:13 ` [PATCH v2 05/21] KVM: arm64: Protect TPIDRRO_EL0 across guest entry/exit Will Deacon
2026-09-30 20:55   ` Linus Walleij
2026-10-08  7:45   ` Jinjie Ruan
2026-09-18 16:13 ` [PATCH v2 06/21] arm64: Store 'current' in TPIDRRO_EL0 instead of SP_EL0 Will Deacon
2026-09-30 20:58   ` Linus Walleij
2026-10-08  7:29   ` Jinjie Ruan
2026-09-18 16:13 ` [PATCH v2 07/21] selftests/bpf: arm64: Use TPIDRRO_EL0 instead of SP_EL0 for 'current' Will Deacon
2026-09-30 20:58   ` Linus Walleij
2026-10-08  7:55   ` Jinjie Ruan
2026-09-18 16:13 ` [PATCH v2 08/21] scripts/gdb: " Will Deacon
2026-09-30 20:59   ` Linus Walleij
2026-10-08  7:56   ` Jinjie Ruan
2026-09-18 16:13 ` [PATCH v2 09/21] arm64: stackprotector: Re-enable per-task stackprotector Will Deacon
2026-09-30 21:00   ` Linus Walleij
2026-10-08  7:58   ` Jinjie Ruan
2026-09-18 16:13 ` [PATCH v2 10/21] arm64: percpu: Specialise set_my_cpu_offset() for the primary CPU Will Deacon
2026-09-30 21:02   ` Linus Walleij
2026-10-08  8:12   ` Jinjie Ruan
2026-09-18 16:13 ` [PATCH v2 11/21] arm64: percpu: Annotate __kern_my_cpu_offset() as '__always_inline' Will Deacon
2026-09-30 21:05   ` Linus Walleij
2026-09-30 21:05   ` Linus Walleij
2026-10-08  8:14   ` Jinjie Ruan
2026-09-18 16:13 ` [PATCH v2 12/21] KVM: arm64: Preserve handler/thread bit of EL1 mode in __finalise_el2() Will Deacon
2026-09-18 16:13 ` [PATCH v2 13/21] arm64: sdei: Guard most of asm/sdei.h with CONFIG_ARM_SDE_INTERFACE Will Deacon
2026-09-18 16:13 ` [PATCH v2 14/21] arm64: sdei: Support SDEI events from kernel handler and thread modes Will Deacon
2026-09-18 16:13 ` [PATCH v2 15/21] arm64: entry: Point SP_EL0 at the overflow stack Will Deacon
2026-09-21 15:56   ` Catalin Marinas [this message]
2026-10-08 11:22   ` Jinjie Ruan
2026-09-18 16:14 ` [PATCH v2 16/21] arm64: entry: Implement EL1t exception handlers for " Will Deacon
2026-09-30 21:17   ` Linus Walleij
2026-10-08 11:47   ` Jinjie Ruan
2026-09-18 16:14 ` [PATCH v2 17/21] arm64: entry: Use SPSel to switch to " Will Deacon
2026-09-30 21:22   ` Linus Walleij
2026-10-08 11:59   ` Jinjie Ruan
2026-09-18 16:14 ` [PATCH v2 18/21] arm64: entry: Split up kernel_ventry macro into separate helper macros Will Deacon
2026-09-30 21:26   ` Linus Walleij
2026-10-08  8:53   ` Jinjie Ruan
2026-09-18 16:14 ` [PATCH v2 19/21] arm64: entry: The great stack switcheroo Will Deacon
2026-09-19 11:41   ` Bradley Morgan
2026-09-22 13:51   ` Catalin Marinas
2026-09-30 21:36   ` Linus Walleij
2026-10-01  7:27     ` Will Deacon
2026-10-01  8:38       ` Linus Walleij
2026-10-01 11:32         ` Will Deacon
2026-10-01 11:35           ` Linus Walleij
2026-09-18 16:14 ` [PATCH v2 20/21] arm64: tracing: Advertise a mode of EL1t in synthetic kernel regs Will Deacon
2026-09-22 14:00   ` Catalin Marinas
2026-09-18 16:14 ` [PATCH v2 21/21] arm64: Rename 'overflow_stack' and OVERFLOW_STACK_SIZE Will Deacon
2026-09-22 14:01   ` Catalin Marinas
2026-09-24 12:30 ` [PATCH v2 00/21] arm64: Move overflow sp into SP_EL1 and kernel sp into SP_EL0 Usama Anjum
2026-09-30 21:42 ` Linus Walleij
2026-10-01  7:21   ` Will Deacon
2026-10-01  9:00     ` Muhammad Usama Anjum
2026-10-01 21:19       ` Linus Walleij

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=arFTvxg2FJQUV7qt@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=david@kernel.org \
    --cc=linusw@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=smostafa@google.com \
    --cc=vladimir.murzin@arm.com \
    --cc=will@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.