From: Conor Dooley conor.dooley@microchip.com
Guenter reported a lockdep splat that appears to have been present for a while in v6.1.y & the backports of the riscv_patch_in_stop_machine dance did nothing to help here, as the lock is not being taken when patch_text_nosync() is called in riscv_cpufeature_patch_func(). Add the lock/unlock; elide the splat.
Fixes: c15ac4fd60d5 ("riscv/ftrace: Add dynamic function tracer support") Reported-by: Guenter Roeck linux@roeck-us.net cc: stable@vger.kernel.org Signed-off-by: Conor Dooley conor.dooley@microchip.com --- arch/riscv/kernel/cpufeature.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c index 694267d1fe81..fd1238df6149 100644 --- a/arch/riscv/kernel/cpufeature.c +++ b/arch/riscv/kernel/cpufeature.c @@ -9,6 +9,7 @@ #include <linux/bitmap.h> #include <linux/ctype.h> #include <linux/libfdt.h> +#include <linux/memory.h> #include <linux/module.h> #include <linux/of.h> #include <asm/alternative.h> @@ -316,8 +317,11 @@ void __init_or_module riscv_cpufeature_patch_func(struct alt_entry *begin, }
tmp = (1U << alt->errata_id); - if (cpu_req_feature & tmp) + if (cpu_req_feature & tmp) { + mutex_lock(&text_mutex); patch_text_nosync(alt->old_ptr, alt->alt_ptr, alt->alt_len); + mutex_unlock(&text_mutex); + } } } #endif
On Tue, May 09, 2023 at 10:36:42PM +0100, Conor Dooley wrote:
From: Conor Dooley conor.dooley@microchip.com
Guenter reported a lockdep splat that appears to have been present for a while in v6.1.y & the backports of the riscv_patch_in_stop_machine dance did nothing to help here, as the lock is not being taken when patch_text_nosync() is called in riscv_cpufeature_patch_func(). Add the lock/unlock; elide the splat.
Is this not a problem upstream?
On Thu, May 11, 2023 at 07:39:25PM -0400, Sasha Levin wrote:
On Tue, May 09, 2023 at 10:36:42PM +0100, Conor Dooley wrote:
From: Conor Dooley conor.dooley@microchip.com
Guenter reported a lockdep splat that appears to have been present for a while in v6.1.y & the backports of the riscv_patch_in_stop_machine dance did nothing to help here, as the lock is not being taken when patch_text_nosync() is called in riscv_cpufeature_patch_func(). Add the lock/unlock; elide the splat.
Is this not a problem upstream?
It is not. Nor is it a problem in 6.2 either. In fact, looking at it at a time other than 22h30, I notice that this is not a complete patch. Instead we need to backport commit 9493e6f3ce02 ("RISC-V: take text_mutex during alternative patching") and bf89b7ee52af ("RISC-V: fix taking the text_mutex twice during sifive errata patching") to 6.1. The automagic version failed: https://lore.kernel.org/stable/a2a21e9c-41ec-46dd-b792-6314c5fa4241@spud/
And I was of the opinion that this was not needed for kernels without commit 702e64550b12 ("riscv: fpu: switch has_fpu() to riscv_has_extension_likely()").
I'll go send those now, I am surprised noone has complained about the SiFive errata causing a splat, but I guess noone with that hardware is testing stable. The T-HEAD errata has no functional users in 6.1.
Thanks, Conor.
linux-stable-mirror@lists.linaro.org