All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: linux-omap@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org,
	Ard Biesheuvel <ardb@kernel.org>, Arnd Bergmann <arnd@arndb.de>
Subject: [PATCHv2] ARM: OMAP2+: Fix regression for smc calls for vmap stack
Date: Thu, 31 Mar 2022 20:17:37 +0300	[thread overview]
Message-ID: <20220331171737.48211-1-tony@atomide.com> (raw)

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. For omap_secure_dispatcher(), we need
to use a cpu specific buffer as there's nothing currently ensuring it only
gets called from cpu0.

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 | 13 ++++++++++---
 1 file changed, 10 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,13 @@ 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 buf[NR_CPUS][5];
+	u32 *param;
+	int cpu;
 	u32 ret;
-	u32 param[5];
+
+	cpu = get_cpu();
+	param = buf[cpu];
 
 	param[0] = nargs;
 	param[1] = arg1;
@@ -76,6 +81,8 @@ u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs, u32 arg1, u32 arg2,
 	outer_clean_range(__pa(param), __pa(param + 5));
 	ret = omap_smc2(idx, flag, __pa(param));
 
+	put_cpu();
+
 	return ret;
 }
 
@@ -119,8 +126,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 +160,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

WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: linux-omap@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org,
	Ard Biesheuvel <ardb@kernel.org>, Arnd Bergmann <arnd@arndb.de>
Subject: [PATCHv2] ARM: OMAP2+: Fix regression for smc calls for vmap stack
Date: Thu, 31 Mar 2022 20:17:37 +0300	[thread overview]
Message-ID: <20220331171737.48211-1-tony@atomide.com> (raw)

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. For omap_secure_dispatcher(), we need
to use a cpu specific buffer as there's nothing currently ensuring it only
gets called from cpu0.

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 | 13 ++++++++++---
 1 file changed, 10 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,13 @@ 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 buf[NR_CPUS][5];
+	u32 *param;
+	int cpu;
 	u32 ret;
-	u32 param[5];
+
+	cpu = get_cpu();
+	param = buf[cpu];
 
 	param[0] = nargs;
 	param[1] = arg1;
@@ -76,6 +81,8 @@ u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs, u32 arg1, u32 arg2,
 	outer_clean_range(__pa(param), __pa(param + 5));
 	ret = omap_smc2(idx, flag, __pa(param));
 
+	put_cpu();
+
 	return ret;
 }
 
@@ -119,8 +126,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 +160,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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2022-03-31 17:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-31 17:17 Tony Lindgren [this message]
2022-03-31 17:17 ` [PATCHv2] ARM: OMAP2+: Fix regression for smc calls for vmap stack Tony Lindgren
2022-03-31 18:47 ` Ard Biesheuvel
2022-03-31 18:47   ` Ard Biesheuvel

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=20220331171737.48211-1-tony@atomide.com \
    --to=tony@atomide.com \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.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.