| Message ID | 20220331144225.56553-1-tony@atomide.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ARM: OMAP2+: Fix regression for smc calls for vmap stack | expand |
On Thu, Mar 31, 2022 at 4:42 PM Tony Lindgren <tony@atomide.com> wrote: > diff --git a/arch/arm/mach-omap2/omap-secure.c b/arch/arm/mach-omap2/omap-secure.c > --- a/arch/arm/mach-omap2/omap-secure.c > +++ b/arch/arm/mach-omap2/omap-secure.c > @@ -59,8 +59,8 @@ static void __init omap_optee_init_check(void) > u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs, u32 arg1, u32 arg2, > u32 arg3, u32 arg4) > { > + static u32 param[5]; > u32 ret; > - u32 param[5]; I think for this one, you do need to use a DEFINE_PER_CPU() to make it work when multiple cores run into the function concurrently. This is entered on OMAP44xx from irq_notifier() with cmd==CPU_CLUSTER_PM_ENTER and from start_secondary(). I suspect that one can show these never happen on more than one CPU at a time, but I have not been able to prove that myself. > @@ -119,8 +119,8 @@ phys_addr_t omap_secure_ram_mempool_base(void) > #if defined(CONFIG_ARCH_OMAP3) && defined(CONFIG_PM) > u32 omap3_save_secure_ram(void __iomem *addr, int size) > { > + static u32 param[5]; > u32 ret; > - u32 param[5]; > > if (size != OMAP3_SAVE_SECURE_RAM_SZ) > return OMAP3_SAVE_SECURE_RAM_SZ; > @@ -153,8 +153,8 @@ u32 omap3_save_secure_ram(void __iomem *addr, int size) > u32 rx51_secure_dispatcher(u32 idx, u32 process, u32 flag, u32 nargs, > u32 arg1, u32 arg2, u32 arg3, u32 arg4) > { > + static u32 param[5]; > u32 ret; > - u32 param[5]; > > param[0] = nargs+1; /* RX-51 needs number of arguments + 1 */ > param[1] = arg1; These look good, as they are clearly only run on single-core SoCs with preemption disabled. Arnd
* Arnd Bergmann <arnd@arndb.de> [220331 15:25]: > On Thu, Mar 31, 2022 at 4:42 PM Tony Lindgren <tony@atomide.com> wrote: > > diff --git a/arch/arm/mach-omap2/omap-secure.c b/arch/arm/mach-omap2/omap-secure.c > > --- a/arch/arm/mach-omap2/omap-secure.c > > +++ b/arch/arm/mach-omap2/omap-secure.c > > @@ -59,8 +59,8 @@ static void __init omap_optee_init_check(void) > > u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs, u32 arg1, u32 arg2, > > u32 arg3, u32 arg4) > > { > > + static u32 param[5]; > > u32 ret; > > - u32 param[5]; > > I think for this one, you do need to use a DEFINE_PER_CPU() to make it > work when multiple cores run into the function concurrently. This is entered > on OMAP44xx from irq_notifier() with cmd==CPU_CLUSTER_PM_ENTER > and from start_secondary(). I suspect that one can show these never happen > on more than one CPU at a time, but I have not been able to prove that > myself. Yeah makes sense. Will post v2. Regards, Tony
diff --git a/arch/arm/mach-omap2/omap-secure.c b/arch/arm/mach-omap2/omap-secure.c --- a/arch/arm/mach-omap2/omap-secure.c +++ b/arch/arm/mach-omap2/omap-secure.c @@ -59,8 +59,8 @@ static void __init omap_optee_init_check(void) u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs, u32 arg1, u32 arg2, u32 arg3, u32 arg4) { + static u32 param[5]; u32 ret; - u32 param[5]; param[0] = nargs; param[1] = arg1; @@ -119,8 +119,8 @@ phys_addr_t omap_secure_ram_mempool_base(void) #if defined(CONFIG_ARCH_OMAP3) && defined(CONFIG_PM) u32 omap3_save_secure_ram(void __iomem *addr, int size) { + static u32 param[5]; u32 ret; - u32 param[5]; if (size != OMAP3_SAVE_SECURE_RAM_SZ) return OMAP3_SAVE_SECURE_RAM_SZ; @@ -153,8 +153,8 @@ u32 omap3_save_secure_ram(void __iomem *addr, int size) u32 rx51_secure_dispatcher(u32 idx, u32 process, u32 flag, u32 nargs, u32 arg1, u32 arg2, u32 arg3, u32 arg4) { + static u32 param[5]; u32 ret; - u32 param[5]; param[0] = nargs+1; /* RX-51 needs number of arguments + 1 */ param[1] = arg1;
Commit 9c46929e7989 ("ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems") started triggering an issue with smc calls hanging on boot as VMAP_STACK is now enabled by default. Based on discussions on the #armlinux irc channel, Arnd noticed that omaps are using __pa() for stack for smc calls. This does not work with vmap stack. Let's fix the issue by changing the param arrays to use static param[5] for each function for __pa() to work. This consumes a bit more memory compared to adding a single static buffer, but avoids potential races with the smc calls initializing the shared buffer. Fixes: 9c46929e7989 ("ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems") Suggested-by: Ard Biesheuvel <ardb@kernel.org> Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Tony Lindgren <tony@atomide.com> --- arch/arm/mach-omap2/omap-secure.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)