* [PATCH] ARM: OMAP2+: Fix regression for smc calls for vmap stack
@ 2022-03-31 14:42 Tony Lindgren
2022-03-31 15:26 ` Arnd Bergmann
0 siblings, 1 reply; 3+ messages in thread
From: Tony Lindgren @ 2022-03-31 14:42 UTC (permalink / raw)
To: linux-omap; +Cc: linux-arm-kernel, Ard Biesheuvel, Arnd Bergmann
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(-)
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;
--
2.35.1
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] ARM: OMAP2+: Fix regression for smc calls for vmap stack
2022-03-31 14:42 [PATCH] ARM: OMAP2+: Fix regression for smc calls for vmap stack Tony Lindgren
@ 2022-03-31 15:26 ` Arnd Bergmann
2022-03-31 16:30 ` Tony Lindgren
0 siblings, 1 reply; 3+ messages in thread
From: Arnd Bergmann @ 2022-03-31 15:26 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, Linux ARM, Ard Biesheuvel, Arnd Bergmann
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] ARM: OMAP2+: Fix regression for smc calls for vmap stack
2022-03-31 15:26 ` Arnd Bergmann
@ 2022-03-31 16:30 ` Tony Lindgren
0 siblings, 0 replies; 3+ messages in thread
From: Tony Lindgren @ 2022-03-31 16:30 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-omap, Linux ARM, Ard Biesheuvel
* 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-03-31 16:30 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-03-31 14:42 [PATCH] ARM: OMAP2+: Fix regression for smc calls for vmap stack Tony Lindgren
2022-03-31 15:26 ` Arnd Bergmann
2022-03-31 16:30 ` Tony Lindgren
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).