* [PATCH v1] RISC-V: take text_mutex during alternative patching
@ 2023-02-12 19:47 Conor Dooley
2023-02-12 19:58 ` Samuel Holland
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: Conor Dooley @ 2023-02-12 19:47 UTC (permalink / raw)
To: palmer; +Cc: conor, Conor Dooley, samuel, linux, linux-riscv, ajones
From: Conor Dooley <conor.dooley@microchip.com>
Guenter reported a splat during boot, that Samuel pointed out was the
lockdep assertion failing in patch_insn_write():
WARNING: CPU: 0 PID: 0 at arch/riscv/kernel/patch.c:63 patch_insn_write+0x222/0x2f6
epc : patch_insn_write+0x222/0x2f6
ra : patch_insn_write+0x21e/0x2f6
epc : ffffffff800068c6 ra : ffffffff800068c2 sp : ffffffff81803df0
gp : ffffffff81a1ab78 tp : ffffffff81814f80 t0 : ffffffffffffe000
t1 : 0000000000000001 t2 : 4c45203a76637369 s0 : ffffffff81803e40
s1 : 0000000000000004 a0 : 0000000000000000 a1 : ffffffffffffffff
a2 : 0000000000000004 a3 : 0000000000000000 a4 : 0000000000000001
a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000052464e43
s2 : ffffffff80b4889c s3 : 000000000000082c s4 : ffffffff80b48828
s5 : 0000000000000828 s6 : ffffffff8131a0a0 s7 : 0000000000000fff
s8 : 0000000008000200 s9 : ffffffff8131a520 s10: 0000000000000018
s11: 000000000000000b t3 : 0000000000000001 t4 : 000000000000000d
t5 : ffffffffd8180000 t6 : ffffffff81803bc8
status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003
[<ffffffff800068c6>] patch_insn_write+0x222/0x2f6
[<ffffffff80006a36>] patch_text_nosync+0xc/0x2a
[<ffffffff80003b86>] riscv_cpufeature_patch_func+0x52/0x98
[<ffffffff80003348>] _apply_alternatives+0x46/0x86
[<ffffffff80c02d36>] apply_boot_alternatives+0x3c/0xfa
[<ffffffff80c03ad8>] setup_arch+0x584/0x5b8
[<ffffffff80c0075a>] start_kernel+0xa2/0x8f8
This issue was exposed by 702e64550b12 ("riscv: fpu: switch has_fpu() to
riscv_has_extension_likely()"), as it is the patching in has_fpu() that
triggers the splats in Guenter's report.
Take the text_mutex before doing any code patching to satisfy lockdep.
Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support")
Fixes: a35707c3d850 ("riscv: add memory-type errata for T-Head")
Fixes: 1a0e5dbd3723 ("riscv: sifive: Add SiFive alternative ports")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/all/20230212154333.GA3760469@roeck-us.net/
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
Applies on top of Samuel's critical fixes in his "Fix alternatives
issues on for-next":
https://lore.kernel.org/all/20230212021534.59121-1-samuel@sholland.org/
---
arch/riscv/errata/sifive/errata.c | 3 +++
arch/riscv/errata/thead/errata.c | 8 ++++++--
arch/riscv/kernel/cpufeature.c | 4 ++++
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/errata/sifive/errata.c b/arch/riscv/errata/sifive/errata.c
index ef9a4eec0dba..da55cb247e89 100644
--- a/arch/riscv/errata/sifive/errata.c
+++ b/arch/riscv/errata/sifive/errata.c
@@ -4,6 +4,7 @@
*/
#include <linux/kernel.h>
+#include <linux/memory.h>
#include <linux/module.h>
#include <linux/string.h>
#include <linux/bug.h>
@@ -107,8 +108,10 @@ void __init_or_module sifive_errata_patch_func(struct alt_entry *begin,
tmp = (1U << alt->errata_id);
if (cpu_req_errata & tmp) {
+ mutex_lock(&text_mutex);
patch_text_nosync(ALT_OLD_PTR(alt), ALT_ALT_PTR(alt),
alt->alt_len);
+ mutex_lock(&text_mutex);
cpu_apply_errata |= tmp;
}
}
diff --git a/arch/riscv/errata/thead/errata.c b/arch/riscv/errata/thead/errata.c
index 1dd90a5f86f0..3b96a06d3c54 100644
--- a/arch/riscv/errata/thead/errata.c
+++ b/arch/riscv/errata/thead/errata.c
@@ -5,6 +5,7 @@
#include <linux/bug.h>
#include <linux/kernel.h>
+#include <linux/memory.h>
#include <linux/module.h>
#include <linux/string.h>
#include <linux/uaccess.h>
@@ -101,10 +102,13 @@ void __init_or_module thead_errata_patch_func(struct alt_entry *begin, struct al
altptr = ALT_ALT_PTR(alt);
/* On vm-alternatives, the mmu isn't running yet */
- if (stage == RISCV_ALTERNATIVES_EARLY_BOOT)
+ if (stage == RISCV_ALTERNATIVES_EARLY_BOOT) {
memcpy(oldptr, altptr, alt->alt_len);
- else
+ } else {
+ mutex_lock(&text_mutex);
patch_text_nosync(oldptr, altptr, alt->alt_len);
+ mutex_unlock(&text_mutex);
+ }
}
}
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 21fb567e1b22..59d58ee0f68d 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -10,6 +10,7 @@
#include <linux/ctype.h>
#include <linux/libfdt.h>
#include <linux/log2.h>
+#include <linux/memory.h>
#include <linux/module.h>
#include <linux/of.h>
#include <asm/alternative.h>
@@ -292,8 +293,11 @@ void __init_or_module riscv_cpufeature_patch_func(struct alt_entry *begin,
oldptr = ALT_OLD_PTR(alt);
altptr = ALT_ALT_PTR(alt);
+
+ mutex_lock(&text_mutex);
patch_text_nosync(oldptr, altptr, alt->alt_len);
riscv_alternative_fix_offsets(oldptr, alt->alt_len, oldptr - altptr);
+ mutex_unlock(&text_mutex);
}
}
#endif
--
2.39.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH v1] RISC-V: take text_mutex during alternative patching 2023-02-12 19:47 [PATCH v1] RISC-V: take text_mutex during alternative patching Conor Dooley @ 2023-02-12 19:58 ` Samuel Holland 2023-02-12 23:08 ` Guenter Roeck 2023-02-22 15:00 ` [PATCH v1] RISC-V: take text_mutex during alternative patching patchwork-bot+linux-riscv 2 siblings, 0 replies; 20+ messages in thread From: Samuel Holland @ 2023-02-12 19:58 UTC (permalink / raw) To: Conor Dooley, palmer; +Cc: Conor Dooley, linux, linux-riscv, ajones On 2/12/23 13:47, Conor Dooley wrote: > From: Conor Dooley <conor.dooley@microchip.com> > > Guenter reported a splat during boot, that Samuel pointed out was the > lockdep assertion failing in patch_insn_write(): > > WARNING: CPU: 0 PID: 0 at arch/riscv/kernel/patch.c:63 patch_insn_write+0x222/0x2f6 > epc : patch_insn_write+0x222/0x2f6 > ra : patch_insn_write+0x21e/0x2f6 > epc : ffffffff800068c6 ra : ffffffff800068c2 sp : ffffffff81803df0 > gp : ffffffff81a1ab78 tp : ffffffff81814f80 t0 : ffffffffffffe000 > t1 : 0000000000000001 t2 : 4c45203a76637369 s0 : ffffffff81803e40 > s1 : 0000000000000004 a0 : 0000000000000000 a1 : ffffffffffffffff > a2 : 0000000000000004 a3 : 0000000000000000 a4 : 0000000000000001 > a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000052464e43 > s2 : ffffffff80b4889c s3 : 000000000000082c s4 : ffffffff80b48828 > s5 : 0000000000000828 s6 : ffffffff8131a0a0 s7 : 0000000000000fff > s8 : 0000000008000200 s9 : ffffffff8131a520 s10: 0000000000000018 > s11: 000000000000000b t3 : 0000000000000001 t4 : 000000000000000d > t5 : ffffffffd8180000 t6 : ffffffff81803bc8 > status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 > [<ffffffff800068c6>] patch_insn_write+0x222/0x2f6 > [<ffffffff80006a36>] patch_text_nosync+0xc/0x2a > [<ffffffff80003b86>] riscv_cpufeature_patch_func+0x52/0x98 > [<ffffffff80003348>] _apply_alternatives+0x46/0x86 > [<ffffffff80c02d36>] apply_boot_alternatives+0x3c/0xfa > [<ffffffff80c03ad8>] setup_arch+0x584/0x5b8 > [<ffffffff80c0075a>] start_kernel+0xa2/0x8f8 > > This issue was exposed by 702e64550b12 ("riscv: fpu: switch has_fpu() to > riscv_has_extension_likely()"), as it is the patching in has_fpu() that > triggers the splats in Guenter's report. > > Take the text_mutex before doing any code patching to satisfy lockdep. > > Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support") > Fixes: a35707c3d850 ("riscv: add memory-type errata for T-Head") > Fixes: 1a0e5dbd3723 ("riscv: sifive: Add SiFive alternative ports") > Reported-by: Guenter Roeck <linux@roeck-us.net> > Link: https://lore.kernel.org/all/20230212154333.GA3760469@roeck-us.net/ > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > --- > Applies on top of Samuel's critical fixes in his "Fix alternatives > issues on for-next": > https://lore.kernel.org/all/20230212021534.59121-1-samuel@sholland.org/ > --- > arch/riscv/errata/sifive/errata.c | 3 +++ > arch/riscv/errata/thead/errata.c | 8 ++++++-- > arch/riscv/kernel/cpufeature.c | 4 ++++ > 3 files changed, 13 insertions(+), 2 deletions(-) Reviewed-by: Samuel Holland <samuel@sholland.org> _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v1] RISC-V: take text_mutex during alternative patching 2023-02-12 19:47 [PATCH v1] RISC-V: take text_mutex during alternative patching Conor Dooley 2023-02-12 19:58 ` Samuel Holland @ 2023-02-12 23:08 ` Guenter Roeck 2023-02-13 22:40 ` Conor Dooley 2023-02-22 15:00 ` [PATCH v1] RISC-V: take text_mutex during alternative patching patchwork-bot+linux-riscv 2 siblings, 1 reply; 20+ messages in thread From: Guenter Roeck @ 2023-02-12 23:08 UTC (permalink / raw) To: Conor Dooley, palmer; +Cc: Conor Dooley, samuel, linux-riscv, ajones On 2/12/23 11:47, Conor Dooley wrote: > From: Conor Dooley <conor.dooley@microchip.com> > > Guenter reported a splat during boot, that Samuel pointed out was the > lockdep assertion failing in patch_insn_write(): > > WARNING: CPU: 0 PID: 0 at arch/riscv/kernel/patch.c:63 patch_insn_write+0x222/0x2f6 > epc : patch_insn_write+0x222/0x2f6 > ra : patch_insn_write+0x21e/0x2f6 > epc : ffffffff800068c6 ra : ffffffff800068c2 sp : ffffffff81803df0 > gp : ffffffff81a1ab78 tp : ffffffff81814f80 t0 : ffffffffffffe000 > t1 : 0000000000000001 t2 : 4c45203a76637369 s0 : ffffffff81803e40 > s1 : 0000000000000004 a0 : 0000000000000000 a1 : ffffffffffffffff > a2 : 0000000000000004 a3 : 0000000000000000 a4 : 0000000000000001 > a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000052464e43 > s2 : ffffffff80b4889c s3 : 000000000000082c s4 : ffffffff80b48828 > s5 : 0000000000000828 s6 : ffffffff8131a0a0 s7 : 0000000000000fff > s8 : 0000000008000200 s9 : ffffffff8131a520 s10: 0000000000000018 > s11: 000000000000000b t3 : 0000000000000001 t4 : 000000000000000d > t5 : ffffffffd8180000 t6 : ffffffff81803bc8 > status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 > [<ffffffff800068c6>] patch_insn_write+0x222/0x2f6 > [<ffffffff80006a36>] patch_text_nosync+0xc/0x2a > [<ffffffff80003b86>] riscv_cpufeature_patch_func+0x52/0x98 > [<ffffffff80003348>] _apply_alternatives+0x46/0x86 > [<ffffffff80c02d36>] apply_boot_alternatives+0x3c/0xfa > [<ffffffff80c03ad8>] setup_arch+0x584/0x5b8 > [<ffffffff80c0075a>] start_kernel+0xa2/0x8f8 > > This issue was exposed by 702e64550b12 ("riscv: fpu: switch has_fpu() to > riscv_has_extension_likely()"), as it is the patching in has_fpu() that > triggers the splats in Guenter's report. > > Take the text_mutex before doing any code patching to satisfy lockdep. > > Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support") > Fixes: a35707c3d850 ("riscv: add memory-type errata for T-Head") > Fixes: 1a0e5dbd3723 ("riscv: sifive: Add SiFive alternative ports") > Reported-by: Guenter Roeck <linux@roeck-us.net> > Link: https://lore.kernel.org/all/20230212154333.GA3760469@roeck-us.net/ > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Applying this patch together with riscv: Fix early alternative patching riscv: Fix Zbb alternative IDs _and_ disabling CONFIG_RISCV_ISA_ZBB fixes all problems observed with riscv64 for me. With that, Tested-by: Guenter Roeck <linux@roeck-us.net> Unfortunately I still see boot failures when trying to boot riscv32 images, so something is still broken. I don't know yet if that is a generic problem or if it is related to a riscv patch. I am still trying to track that down ... Guenter > --- > Applies on top of Samuel's critical fixes in his "Fix alternatives > issues on for-next": > https://lore.kernel.org/all/20230212021534.59121-1-samuel@sholland.org/ > --- > arch/riscv/errata/sifive/errata.c | 3 +++ > arch/riscv/errata/thead/errata.c | 8 ++++++-- > arch/riscv/kernel/cpufeature.c | 4 ++++ > 3 files changed, 13 insertions(+), 2 deletions(-) > > diff --git a/arch/riscv/errata/sifive/errata.c b/arch/riscv/errata/sifive/errata.c > index ef9a4eec0dba..da55cb247e89 100644 > --- a/arch/riscv/errata/sifive/errata.c > +++ b/arch/riscv/errata/sifive/errata.c > @@ -4,6 +4,7 @@ > */ > > #include <linux/kernel.h> > +#include <linux/memory.h> > #include <linux/module.h> > #include <linux/string.h> > #include <linux/bug.h> > @@ -107,8 +108,10 @@ void __init_or_module sifive_errata_patch_func(struct alt_entry *begin, > > tmp = (1U << alt->errata_id); > if (cpu_req_errata & tmp) { > + mutex_lock(&text_mutex); > patch_text_nosync(ALT_OLD_PTR(alt), ALT_ALT_PTR(alt), > alt->alt_len); > + mutex_lock(&text_mutex); > cpu_apply_errata |= tmp; > } > } > diff --git a/arch/riscv/errata/thead/errata.c b/arch/riscv/errata/thead/errata.c > index 1dd90a5f86f0..3b96a06d3c54 100644 > --- a/arch/riscv/errata/thead/errata.c > +++ b/arch/riscv/errata/thead/errata.c > @@ -5,6 +5,7 @@ > > #include <linux/bug.h> > #include <linux/kernel.h> > +#include <linux/memory.h> > #include <linux/module.h> > #include <linux/string.h> > #include <linux/uaccess.h> > @@ -101,10 +102,13 @@ void __init_or_module thead_errata_patch_func(struct alt_entry *begin, struct al > altptr = ALT_ALT_PTR(alt); > > /* On vm-alternatives, the mmu isn't running yet */ > - if (stage == RISCV_ALTERNATIVES_EARLY_BOOT) > + if (stage == RISCV_ALTERNATIVES_EARLY_BOOT) { > memcpy(oldptr, altptr, alt->alt_len); > - else > + } else { > + mutex_lock(&text_mutex); > patch_text_nosync(oldptr, altptr, alt->alt_len); > + mutex_unlock(&text_mutex); > + } > } > } > > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > index 21fb567e1b22..59d58ee0f68d 100644 > --- a/arch/riscv/kernel/cpufeature.c > +++ b/arch/riscv/kernel/cpufeature.c > @@ -10,6 +10,7 @@ > #include <linux/ctype.h> > #include <linux/libfdt.h> > #include <linux/log2.h> > +#include <linux/memory.h> > #include <linux/module.h> > #include <linux/of.h> > #include <asm/alternative.h> > @@ -292,8 +293,11 @@ void __init_or_module riscv_cpufeature_patch_func(struct alt_entry *begin, > > oldptr = ALT_OLD_PTR(alt); > altptr = ALT_ALT_PTR(alt); > + > + mutex_lock(&text_mutex); > patch_text_nosync(oldptr, altptr, alt->alt_len); > riscv_alternative_fix_offsets(oldptr, alt->alt_len, oldptr - altptr); > + mutex_unlock(&text_mutex); > } > } > #endif _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v1] RISC-V: take text_mutex during alternative patching 2023-02-12 23:08 ` Guenter Roeck @ 2023-02-13 22:40 ` Conor Dooley 2023-02-15 14:43 ` Heiko Stübner 0 siblings, 1 reply; 20+ messages in thread From: Conor Dooley @ 2023-02-13 22:40 UTC (permalink / raw) To: Guenter Roeck, heiko; +Cc: palmer, Conor Dooley, samuel, linux-riscv, ajones [-- Attachment #1.1: Type: text/plain, Size: 3086 bytes --] +CC Heiko On Sun, Feb 12, 2023 at 03:08:55PM -0800, Guenter Roeck wrote: > On 2/12/23 11:47, Conor Dooley wrote: > > From: Conor Dooley <conor.dooley@microchip.com> > > > > Guenter reported a splat during boot, that Samuel pointed out was the > > lockdep assertion failing in patch_insn_write(): > > > > WARNING: CPU: 0 PID: 0 at arch/riscv/kernel/patch.c:63 patch_insn_write+0x222/0x2f6 > > epc : patch_insn_write+0x222/0x2f6 > > ra : patch_insn_write+0x21e/0x2f6 > > epc : ffffffff800068c6 ra : ffffffff800068c2 sp : ffffffff81803df0 > > gp : ffffffff81a1ab78 tp : ffffffff81814f80 t0 : ffffffffffffe000 > > t1 : 0000000000000001 t2 : 4c45203a76637369 s0 : ffffffff81803e40 > > s1 : 0000000000000004 a0 : 0000000000000000 a1 : ffffffffffffffff > > a2 : 0000000000000004 a3 : 0000000000000000 a4 : 0000000000000001 > > a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000052464e43 > > s2 : ffffffff80b4889c s3 : 000000000000082c s4 : ffffffff80b48828 > > s5 : 0000000000000828 s6 : ffffffff8131a0a0 s7 : 0000000000000fff > > s8 : 0000000008000200 s9 : ffffffff8131a520 s10: 0000000000000018 > > s11: 000000000000000b t3 : 0000000000000001 t4 : 000000000000000d > > t5 : ffffffffd8180000 t6 : ffffffff81803bc8 > > status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 > > [<ffffffff800068c6>] patch_insn_write+0x222/0x2f6 > > [<ffffffff80006a36>] patch_text_nosync+0xc/0x2a > > [<ffffffff80003b86>] riscv_cpufeature_patch_func+0x52/0x98 > > [<ffffffff80003348>] _apply_alternatives+0x46/0x86 > > [<ffffffff80c02d36>] apply_boot_alternatives+0x3c/0xfa > > [<ffffffff80c03ad8>] setup_arch+0x584/0x5b8 > > [<ffffffff80c0075a>] start_kernel+0xa2/0x8f8 > > > > This issue was exposed by 702e64550b12 ("riscv: fpu: switch has_fpu() to > > riscv_has_extension_likely()"), as it is the patching in has_fpu() that > > triggers the splats in Guenter's report. > > > > Take the text_mutex before doing any code patching to satisfy lockdep. > > > > Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support") > > Fixes: a35707c3d850 ("riscv: add memory-type errata for T-Head") > > Fixes: 1a0e5dbd3723 ("riscv: sifive: Add SiFive alternative ports") > > Reported-by: Guenter Roeck <linux@roeck-us.net> > > Link: https://lore.kernel.org/all/20230212154333.GA3760469@roeck-us.net/ > > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > > > Applying this patch together with > > riscv: Fix early alternative patching > riscv: Fix Zbb alternative IDs > > _and_ disabling CONFIG_RISCV_ISA_ZBB fixes all problems observed with > riscv64 for me. With that, > > Tested-by: Guenter Roeck <linux@roeck-us.net> > > Unfortunately I still see boot failures when trying to boot riscv32 > images, so something is still broken. I don't know yet if that is > a generic problem or if it is related to a riscv patch. > I am still trying to track that down ... Heiko, would you be able to look at this please? There's some more information in the Link: above. Thanks Conor. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] [-- Attachment #2: Type: text/plain, Size: 161 bytes --] _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v1] RISC-V: take text_mutex during alternative patching 2023-02-13 22:40 ` Conor Dooley @ 2023-02-15 14:43 ` Heiko Stübner 2023-02-15 22:00 ` Heiko Stübner 0 siblings, 1 reply; 20+ messages in thread From: Heiko Stübner @ 2023-02-15 14:43 UTC (permalink / raw) To: Guenter Roeck, Conor Dooley Cc: palmer, Conor Dooley, samuel, linux-riscv, ajones Hi Conor, Am Montag, 13. Februar 2023, 23:40:38 CET schrieb Conor Dooley: > +CC Heiko > > On Sun, Feb 12, 2023 at 03:08:55PM -0800, Guenter Roeck wrote: > > On 2/12/23 11:47, Conor Dooley wrote: > > > From: Conor Dooley <conor.dooley@microchip.com> > > > > > > Guenter reported a splat during boot, that Samuel pointed out was the > > > lockdep assertion failing in patch_insn_write(): > > > > > > WARNING: CPU: 0 PID: 0 at arch/riscv/kernel/patch.c:63 patch_insn_write+0x222/0x2f6 > > > epc : patch_insn_write+0x222/0x2f6 > > > ra : patch_insn_write+0x21e/0x2f6 > > > epc : ffffffff800068c6 ra : ffffffff800068c2 sp : ffffffff81803df0 > > > gp : ffffffff81a1ab78 tp : ffffffff81814f80 t0 : ffffffffffffe000 > > > t1 : 0000000000000001 t2 : 4c45203a76637369 s0 : ffffffff81803e40 > > > s1 : 0000000000000004 a0 : 0000000000000000 a1 : ffffffffffffffff > > > a2 : 0000000000000004 a3 : 0000000000000000 a4 : 0000000000000001 > > > a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000052464e43 > > > s2 : ffffffff80b4889c s3 : 000000000000082c s4 : ffffffff80b48828 > > > s5 : 0000000000000828 s6 : ffffffff8131a0a0 s7 : 0000000000000fff > > > s8 : 0000000008000200 s9 : ffffffff8131a520 s10: 0000000000000018 > > > s11: 000000000000000b t3 : 0000000000000001 t4 : 000000000000000d > > > t5 : ffffffffd8180000 t6 : ffffffff81803bc8 > > > status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 > > > [<ffffffff800068c6>] patch_insn_write+0x222/0x2f6 > > > [<ffffffff80006a36>] patch_text_nosync+0xc/0x2a > > > [<ffffffff80003b86>] riscv_cpufeature_patch_func+0x52/0x98 > > > [<ffffffff80003348>] _apply_alternatives+0x46/0x86 > > > [<ffffffff80c02d36>] apply_boot_alternatives+0x3c/0xfa > > > [<ffffffff80c03ad8>] setup_arch+0x584/0x5b8 > > > [<ffffffff80c0075a>] start_kernel+0xa2/0x8f8 > > > > > > This issue was exposed by 702e64550b12 ("riscv: fpu: switch has_fpu() to > > > riscv_has_extension_likely()"), as it is the patching in has_fpu() that > > > triggers the splats in Guenter's report. > > > > > > Take the text_mutex before doing any code patching to satisfy lockdep. > > > > > > Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support") > > > Fixes: a35707c3d850 ("riscv: add memory-type errata for T-Head") > > > Fixes: 1a0e5dbd3723 ("riscv: sifive: Add SiFive alternative ports") > > > Reported-by: Guenter Roeck <linux@roeck-us.net> > > > Link: https://lore.kernel.org/all/20230212154333.GA3760469@roeck-us.net/ > > > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > > > > > > Applying this patch together with > > > > riscv: Fix early alternative patching > > riscv: Fix Zbb alternative IDs > > > > _and_ disabling CONFIG_RISCV_ISA_ZBB fixes all problems observed with > > riscv64 for me. With that, > > > > Tested-by: Guenter Roeck <linux@roeck-us.net> > > > > Unfortunately I still see boot failures when trying to boot riscv32 > > images, so something is still broken. I don't know yet if that is > > a generic problem or if it is related to a riscv patch. > > I am still trying to track that down ... > > Heiko, would you be able to look at this please? > There's some more information in the Link: above. just for the record, I started looking into this now. Starting with my own code [0] on top of 6.2-rc2 I was able to verify - qemu-riscv32 without zbb - qemu-riscv32 with zbb - qemu-riscv64 without zbb - qemu-riscv64 with zbb to work. So next up, I'll move over to the merged for-next branch to hopefully see what changed between the above and the for-next code. Heiko [0] https://github.com/mmind/linux-riscv/tree/upstream/strcmp-v5 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v1] RISC-V: take text_mutex during alternative patching 2023-02-15 14:43 ` Heiko Stübner @ 2023-02-15 22:00 ` Heiko Stübner 2023-02-16 0:22 ` Guenter Roeck ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Heiko Stübner @ 2023-02-15 22:00 UTC (permalink / raw) To: Guenter Roeck, Conor Dooley Cc: palmer, Conor Dooley, samuel, linux-riscv, ajones Am Mittwoch, 15. Februar 2023, 15:43:10 CET schrieb Heiko Stübner: > Hi Conor, > > Am Montag, 13. Februar 2023, 23:40:38 CET schrieb Conor Dooley: > > +CC Heiko > > > > On Sun, Feb 12, 2023 at 03:08:55PM -0800, Guenter Roeck wrote: > > > On 2/12/23 11:47, Conor Dooley wrote: > > > > From: Conor Dooley <conor.dooley@microchip.com> > > > > > > > > Guenter reported a splat during boot, that Samuel pointed out was the > > > > lockdep assertion failing in patch_insn_write(): > > > > > > > > WARNING: CPU: 0 PID: 0 at arch/riscv/kernel/patch.c:63 patch_insn_write+0x222/0x2f6 > > > > epc : patch_insn_write+0x222/0x2f6 > > > > ra : patch_insn_write+0x21e/0x2f6 > > > > epc : ffffffff800068c6 ra : ffffffff800068c2 sp : ffffffff81803df0 > > > > gp : ffffffff81a1ab78 tp : ffffffff81814f80 t0 : ffffffffffffe000 > > > > t1 : 0000000000000001 t2 : 4c45203a76637369 s0 : ffffffff81803e40 > > > > s1 : 0000000000000004 a0 : 0000000000000000 a1 : ffffffffffffffff > > > > a2 : 0000000000000004 a3 : 0000000000000000 a4 : 0000000000000001 > > > > a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000052464e43 > > > > s2 : ffffffff80b4889c s3 : 000000000000082c s4 : ffffffff80b48828 > > > > s5 : 0000000000000828 s6 : ffffffff8131a0a0 s7 : 0000000000000fff > > > > s8 : 0000000008000200 s9 : ffffffff8131a520 s10: 0000000000000018 > > > > s11: 000000000000000b t3 : 0000000000000001 t4 : 000000000000000d > > > > t5 : ffffffffd8180000 t6 : ffffffff81803bc8 > > > > status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 > > > > [<ffffffff800068c6>] patch_insn_write+0x222/0x2f6 > > > > [<ffffffff80006a36>] patch_text_nosync+0xc/0x2a > > > > [<ffffffff80003b86>] riscv_cpufeature_patch_func+0x52/0x98 > > > > [<ffffffff80003348>] _apply_alternatives+0x46/0x86 > > > > [<ffffffff80c02d36>] apply_boot_alternatives+0x3c/0xfa > > > > [<ffffffff80c03ad8>] setup_arch+0x584/0x5b8 > > > > [<ffffffff80c0075a>] start_kernel+0xa2/0x8f8 > > > > > > > > This issue was exposed by 702e64550b12 ("riscv: fpu: switch has_fpu() to > > > > riscv_has_extension_likely()"), as it is the patching in has_fpu() that > > > > triggers the splats in Guenter's report. > > > > > > > > Take the text_mutex before doing any code patching to satisfy lockdep. > > > > > > > > Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support") > > > > Fixes: a35707c3d850 ("riscv: add memory-type errata for T-Head") > > > > Fixes: 1a0e5dbd3723 ("riscv: sifive: Add SiFive alternative ports") > > > > Reported-by: Guenter Roeck <linux@roeck-us.net> > > > > Link: https://lore.kernel.org/all/20230212154333.GA3760469@roeck-us.net/ > > > > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > > > > > > > > > Applying this patch together with > > > > > > riscv: Fix early alternative patching > > > riscv: Fix Zbb alternative IDs > > > > > > _and_ disabling CONFIG_RISCV_ISA_ZBB fixes all problems observed with > > > riscv64 for me. With that, > > > > > > Tested-by: Guenter Roeck <linux@roeck-us.net> > > > > > > Unfortunately I still see boot failures when trying to boot riscv32 > > > images, so something is still broken. I don't know yet if that is > > > a generic problem or if it is related to a riscv patch. > > > I am still trying to track that down ... > > > > Heiko, would you be able to look at this please? > > There's some more information in the Link: above. > > just for the record, I started looking into this now. > > Starting with my own code [0] on top of 6.2-rc2 I was able to verify > - qemu-riscv32 without zbb > - qemu-riscv32 with zbb > - qemu-riscv64 without zbb > - qemu-riscv64 with zbb > to work. > > So next up, I'll move over to the merged for-next branch to hopefully > see what changed between the above and the for-next code. So now I've also tested Palmer's for-next at commit ec6311919ea6 ("Merge patch series "riscv: Optimize function trace"") again with the same variants - qemu-riscv32 without zbb - qemu-riscv32 with zbb - qemu-riscv64 without zbb - qemu-riscv64 with zbb And all of them booted fine into a nfs-root (debian for riscv64 and a buildroot for riscv32). I even forced a bug into the zbb code to make sure the patching worked correctly (where the kernel failed as expected). Qemu-version for me was 7.2.50 (v7.2.0-744-g5a3633929a-dirty) I did try the one from Debian-stable (qemu-5.2) but that was too old and didn't support Zbb yet. One thing of note, the "active" 32bit config I had, somehow didn't produce working images and I needed to start a new build using the rv32_defconfig. So right now, I'm not sure what more to test though. Heiko _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v1] RISC-V: take text_mutex during alternative patching 2023-02-15 22:00 ` Heiko Stübner @ 2023-02-16 0:22 ` Guenter Roeck 2023-02-16 7:07 ` Guenter Roeck 2023-02-16 15:33 ` Guenter Roeck 2 siblings, 0 replies; 20+ messages in thread From: Guenter Roeck @ 2023-02-16 0:22 UTC (permalink / raw) To: Heiko Stübner, Conor Dooley Cc: palmer, Conor Dooley, samuel, linux-riscv, ajones On 2/15/23 14:00, Heiko Stübner wrote: > Am Mittwoch, 15. Februar 2023, 15:43:10 CET schrieb Heiko Stübner: >> Hi Conor, >> >> Am Montag, 13. Februar 2023, 23:40:38 CET schrieb Conor Dooley: >>> +CC Heiko >>> >>> On Sun, Feb 12, 2023 at 03:08:55PM -0800, Guenter Roeck wrote: >>>> On 2/12/23 11:47, Conor Dooley wrote: >>>>> From: Conor Dooley <conor.dooley@microchip.com> >>>>> >>>>> Guenter reported a splat during boot, that Samuel pointed out was the >>>>> lockdep assertion failing in patch_insn_write(): >>>>> >>>>> WARNING: CPU: 0 PID: 0 at arch/riscv/kernel/patch.c:63 patch_insn_write+0x222/0x2f6 >>>>> epc : patch_insn_write+0x222/0x2f6 >>>>> ra : patch_insn_write+0x21e/0x2f6 >>>>> epc : ffffffff800068c6 ra : ffffffff800068c2 sp : ffffffff81803df0 >>>>> gp : ffffffff81a1ab78 tp : ffffffff81814f80 t0 : ffffffffffffe000 >>>>> t1 : 0000000000000001 t2 : 4c45203a76637369 s0 : ffffffff81803e40 >>>>> s1 : 0000000000000004 a0 : 0000000000000000 a1 : ffffffffffffffff >>>>> a2 : 0000000000000004 a3 : 0000000000000000 a4 : 0000000000000001 >>>>> a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000052464e43 >>>>> s2 : ffffffff80b4889c s3 : 000000000000082c s4 : ffffffff80b48828 >>>>> s5 : 0000000000000828 s6 : ffffffff8131a0a0 s7 : 0000000000000fff >>>>> s8 : 0000000008000200 s9 : ffffffff8131a520 s10: 0000000000000018 >>>>> s11: 000000000000000b t3 : 0000000000000001 t4 : 000000000000000d >>>>> t5 : ffffffffd8180000 t6 : ffffffff81803bc8 >>>>> status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 >>>>> [<ffffffff800068c6>] patch_insn_write+0x222/0x2f6 >>>>> [<ffffffff80006a36>] patch_text_nosync+0xc/0x2a >>>>> [<ffffffff80003b86>] riscv_cpufeature_patch_func+0x52/0x98 >>>>> [<ffffffff80003348>] _apply_alternatives+0x46/0x86 >>>>> [<ffffffff80c02d36>] apply_boot_alternatives+0x3c/0xfa >>>>> [<ffffffff80c03ad8>] setup_arch+0x584/0x5b8 >>>>> [<ffffffff80c0075a>] start_kernel+0xa2/0x8f8 >>>>> >>>>> This issue was exposed by 702e64550b12 ("riscv: fpu: switch has_fpu() to >>>>> riscv_has_extension_likely()"), as it is the patching in has_fpu() that >>>>> triggers the splats in Guenter's report. >>>>> >>>>> Take the text_mutex before doing any code patching to satisfy lockdep. >>>>> >>>>> Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support") >>>>> Fixes: a35707c3d850 ("riscv: add memory-type errata for T-Head") >>>>> Fixes: 1a0e5dbd3723 ("riscv: sifive: Add SiFive alternative ports") >>>>> Reported-by: Guenter Roeck <linux@roeck-us.net> >>>>> Link: https://lore.kernel.org/all/20230212154333.GA3760469@roeck-us.net/ >>>>> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> >>>> >>>> >>>> Applying this patch together with >>>> >>>> riscv: Fix early alternative patching >>>> riscv: Fix Zbb alternative IDs >>>> >>>> _and_ disabling CONFIG_RISCV_ISA_ZBB fixes all problems observed with >>>> riscv64 for me. With that, >>>> >>>> Tested-by: Guenter Roeck <linux@roeck-us.net> >>>> >>>> Unfortunately I still see boot failures when trying to boot riscv32 >>>> images, so something is still broken. I don't know yet if that is >>>> a generic problem or if it is related to a riscv patch. >>>> I am still trying to track that down ... >>> >>> Heiko, would you be able to look at this please? >>> There's some more information in the Link: above. >> >> just for the record, I started looking into this now. >> >> Starting with my own code [0] on top of 6.2-rc2 I was able to verify >> - qemu-riscv32 without zbb >> - qemu-riscv32 with zbb >> - qemu-riscv64 without zbb >> - qemu-riscv64 with zbb >> to work. >> >> So next up, I'll move over to the merged for-next branch to hopefully >> see what changed between the above and the for-next code. > > So now I've also tested Palmer's for-next at > commit ec6311919ea6 ("Merge patch series "riscv: Optimize function trace"") > > again with the same variants > - qemu-riscv32 without zbb > - qemu-riscv32 with zbb > - qemu-riscv64 without zbb > - qemu-riscv64 with zbb > > And all of them booted fine into a nfs-root (debian for riscv64 and a > buildroot for riscv32). > > I even forced a bug into the zbb code to make sure the patching worked > correctly (where the kernel failed as expected). > > Qemu-version for me was 7.2.50 (v7.2.0-744-g5a3633929a-dirty) > Where did you get this version of qemu from ? Does it posssibly include zbb related fixes/changes on top of v7.2.0 ? I used v7.2.0. I also tried the master branch as of today, but there was no difference. Also, what C compiler and binutils version did you use ? > I did try the one from Debian-stable (qemu-5.2) but that was too old and > didn't support Zbb yet. > > One thing of note, the "active" 32bit config I had, somehow didn't produce > working images and I needed to start a new build using the rv32_defconfig. > My tests use rv32_defconfig as base for 32-bit tests, with various debug options enabled on top. Ok, I gave it another try. The backtraces do _not_ appear if I just use defconfig as base. I'll try to find out what exactly triggers the problem. Thanks, Guenter > So right now, I'm not sure what more to test though. > > Heiko > > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v1] RISC-V: take text_mutex during alternative patching 2023-02-15 22:00 ` Heiko Stübner 2023-02-16 0:22 ` Guenter Roeck @ 2023-02-16 7:07 ` Guenter Roeck 2023-02-16 15:33 ` Guenter Roeck 2 siblings, 0 replies; 20+ messages in thread From: Guenter Roeck @ 2023-02-16 7:07 UTC (permalink / raw) To: Heiko Stübner, Conor Dooley Cc: palmer, Conor Dooley, samuel, linux-riscv, ajones On 2/15/23 14:00, Heiko Stübner wrote: [ ... ] > again with the same variants > - qemu-riscv32 without zbb > - qemu-riscv32 with zbb > - qemu-riscv64 without zbb > - qemu-riscv64 with zbb > > And all of them booted fine into a nfs-root (debian for riscv64 and a > buildroot for riscv32). > > I even forced a bug into the zbb code to make sure the patching worked > correctly (where the kernel failed as expected). > > Qemu-version for me was 7.2.50 (v7.2.0-744-g5a3633929a-dirty) > > I did try the one from Debian-stable (qemu-5.2) but that was too old and > didn't support Zbb yet. > > One thing of note, the "active" 32bit config I had, somehow didn't produce > working images and I needed to start a new build using the rv32_defconfig. > > So right now, I'm not sure what more to test though. > Try this: - Use next-20230216 as base. - Apply RISC-V: take text_mutex during alternative patching RISC-V: Don't check text_mutex during stop_machine on top of it. - Configure defconfig + CONFIG_PROVE_LOCKING. - Run something like qemu-system-riscv64 -M virt -m 512M -no-reboot \ -kernel arch/riscv/boot/Image -initrd rootfs.cpio \ -append "rdinit=/sbin/init console=ttyS0,115200 earlycon=uart8250,mmio,0x10000000,115200" \ -nographic -monitor none That should give you WARNING: CPU: 0 PID: 0 at kernel/trace/trace_events.c:448 trace_event_raw_init+0xde/0x642 ... event neigh_update has unsafe dereference of argument 9 and lots of follow-up messages. I tried with qemu v7.2.0 and qemu master (v7.2.0-1434-g6a50f64ca0). Guenter _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v1] RISC-V: take text_mutex during alternative patching 2023-02-15 22:00 ` Heiko Stübner 2023-02-16 0:22 ` Guenter Roeck 2023-02-16 7:07 ` Guenter Roeck @ 2023-02-16 15:33 ` Guenter Roeck 2023-02-22 14:27 ` Andrew Jones 2 siblings, 1 reply; 20+ messages in thread From: Guenter Roeck @ 2023-02-16 15:33 UTC (permalink / raw) To: Heiko Stübner, Conor Dooley Cc: palmer, Conor Dooley, samuel, linux-riscv, ajones On 2/15/23 14:00, Heiko Stübner wrote: [ ... ] > > So now I've also tested Palmer's for-next at > commit ec6311919ea6 ("Merge patch series "riscv: Optimize function trace"") > > again with the same variants > - qemu-riscv32 without zbb > - qemu-riscv32 with zbb > - qemu-riscv64 without zbb > - qemu-riscv64 with zbb > > And all of them booted fine into a nfs-root (debian for riscv64 and a > buildroot for riscv32). > > I even forced a bug into the zbb code to make sure the patching worked > correctly (where the kernel failed as expected). > > Qemu-version for me was 7.2.50 (v7.2.0-744-g5a3633929a-dirty) > > I did try the one from Debian-stable (qemu-5.2) but that was too old and > didn't support Zbb yet. > > One thing of note, the "active" 32bit config I had, somehow didn't produce > working images and I needed to start a new build using the rv32_defconfig. > > So right now, I'm not sure what more to test though. > Another example: - build defconfig - run qemu-system-riscv64 -M virt -m 512M -no-reboot -kernel arch/riscv/boot/Image \ -snapshot -device virtio-blk-device,drive=d0 -drive file=rootfs.ext2,if=none,id=d0,format=raw \ -append "root=/dev/vda console=ttyS0,115200 earlycon=uart8250,mmio,0x10000000,115200" \ -nographic -monitor none With CONFIG_RISCV_ISA_ZBB=y, that results in [ 0.818263] /dev/root: Can't open blockdev [ 0.818856] VFS: Cannot open root device "/dev/vda" or unknown-block(0,0): error -6 [ 0.819177] Please append a correct "root=" boot option; here are the available partitions: [ 0.819808] fe00 16384 vda [ 0.819944] driver: virtio_blk [ 0.820534] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 0.821101] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.2.0-rc8-next-20230216-00002-g80332825e240 #4 [ 0.821672] Hardware name: riscv-virtio,qemu (DT) [ 0.822050] Call Trace: [ 0.822427] [<ffffffff800053e4>] dump_backtrace+0x1c/0x24 [ 0.822834] [<ffffffff807f90e4>] show_stack+0x2c/0x38 [ 0.823085] [<ffffffff80803aea>] dump_stack_lvl+0x3c/0x54 [ 0.823351] [<ffffffff80803b16>] dump_stack+0x14/0x1c [ 0.823601] [<ffffffff807f944c>] panic+0x102/0x29e [ 0.823834] [<ffffffff80a015e2>] mount_block_root+0x18c/0x23e [ 0.824148] [<ffffffff80a0187c>] mount_root+0x1e8/0x218 [ 0.824398] [<ffffffff80a019ee>] prepare_namespace+0x142/0x184 [ 0.824655] [<ffffffff80a01182>] kernel_init_freeable+0x236/0x25a [ 0.824934] [<ffffffff80804602>] kernel_init+0x1e/0x10a [ 0.825201] [<ffffffff80003560>] ret_from_exception+0x0/0x16 [ 0.826180] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]--- This works fine if CONFIG_RISCV_ISA_ZBB is not enabled. Tested with gcc 11.3, binutils 2.39, qemu v7.2.0 and qemu built from mainline. Guenter _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v1] RISC-V: take text_mutex during alternative patching 2023-02-16 15:33 ` Guenter Roeck @ 2023-02-22 14:27 ` Andrew Jones 2023-02-22 15:31 ` Andrew Jones 2023-02-22 16:17 ` RISC-V Zbb QEMU Boot Failures (was Re: [PATCH v1] RISC-V: take text_mutex during alternative patching) Palmer Dabbelt 0 siblings, 2 replies; 20+ messages in thread From: Andrew Jones @ 2023-02-22 14:27 UTC (permalink / raw) To: Guenter Roeck Cc: Heiko Stübner, Conor Dooley, palmer, Conor Dooley, samuel, linux-riscv On Thu, Feb 16, 2023 at 07:33:55AM -0800, Guenter Roeck wrote: > On 2/15/23 14:00, Heiko Stübner wrote: > [ ... ] > > > > So now I've also tested Palmer's for-next at > > commit ec6311919ea6 ("Merge patch series "riscv: Optimize function trace"") > > > > again with the same variants > > - qemu-riscv32 without zbb > > - qemu-riscv32 with zbb > > - qemu-riscv64 without zbb > > - qemu-riscv64 with zbb > > > > And all of them booted fine into a nfs-root (debian for riscv64 and a > > buildroot for riscv32). > > > > I even forced a bug into the zbb code to make sure the patching worked > > correctly (where the kernel failed as expected). > > > > Qemu-version for me was 7.2.50 (v7.2.0-744-g5a3633929a-dirty) > > > > I did try the one from Debian-stable (qemu-5.2) but that was too old and > > didn't support Zbb yet. > > > > One thing of note, the "active" 32bit config I had, somehow didn't produce > > working images and I needed to start a new build using the rv32_defconfig. > > > > So right now, I'm not sure what more to test though. > > > > Another example: > > - build defconfig > - run > qemu-system-riscv64 -M virt -m 512M -no-reboot -kernel arch/riscv/boot/Image \ > -snapshot -device virtio-blk-device,drive=d0 -drive file=rootfs.ext2,if=none,id=d0,format=raw \ > -append "root=/dev/vda console=ttyS0,115200 earlycon=uart8250,mmio,0x10000000,115200" \ > -nographic -monitor none > > With CONFIG_RISCV_ISA_ZBB=y, that results in > > [ 0.818263] /dev/root: Can't open blockdev > [ 0.818856] VFS: Cannot open root device "/dev/vda" or unknown-block(0,0): error -6 > [ 0.819177] Please append a correct "root=" boot option; here are the available partitions: > [ 0.819808] fe00 16384 vda > [ 0.819944] driver: virtio_blk > [ 0.820534] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) > [ 0.821101] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.2.0-rc8-next-20230216-00002-g80332825e240 #4 > [ 0.821672] Hardware name: riscv-virtio,qemu (DT) > [ 0.822050] Call Trace: > [ 0.822427] [<ffffffff800053e4>] dump_backtrace+0x1c/0x24 > [ 0.822834] [<ffffffff807f90e4>] show_stack+0x2c/0x38 > [ 0.823085] [<ffffffff80803aea>] dump_stack_lvl+0x3c/0x54 > [ 0.823351] [<ffffffff80803b16>] dump_stack+0x14/0x1c > [ 0.823601] [<ffffffff807f944c>] panic+0x102/0x29e > [ 0.823834] [<ffffffff80a015e2>] mount_block_root+0x18c/0x23e > [ 0.824148] [<ffffffff80a0187c>] mount_root+0x1e8/0x218 > [ 0.824398] [<ffffffff80a019ee>] prepare_namespace+0x142/0x184 > [ 0.824655] [<ffffffff80a01182>] kernel_init_freeable+0x236/0x25a > [ 0.824934] [<ffffffff80804602>] kernel_init+0x1e/0x10a > [ 0.825201] [<ffffffff80003560>] ret_from_exception+0x0/0x16 > [ 0.826180] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]--- > > This works fine if CONFIG_RISCV_ISA_ZBB is not enabled. > > Tested with gcc 11.3, binutils 2.39, qemu v7.2.0 and qemu built from mainline. > Just to +1 this, I get the same result (unable to mount root fs) with $QEMU -cpu rv64,zbb=on \ -nographic \ -machine virt \ -kernel $KERNEL \ -append 'root=/dev/vda console=ttyS0' \ -drive file=disk.ext4,format=raw,id=hd0 \ -device virtio-blk-pci,drive=hd0 kernel: latest riscv-linux/for-next (8658db0a4a0f), defconfig gcc: riscv-gnu-toolchain (12.1.0) binutils: riscv-gnu-toolchain (2.39) qemu: latest master (79b677d658d3) Flipping the QEMU cpu zbb property off allows boot to succeed, i.e. it's not necessary to compile out the CONFIG_RISCV_ISA_ZBB code from the kernel, it's just necessary to avoid using it. Thanks, drew _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v1] RISC-V: take text_mutex during alternative patching 2023-02-22 14:27 ` Andrew Jones @ 2023-02-22 15:31 ` Andrew Jones 2023-02-22 15:39 ` Heiko Stübner 2023-02-22 16:17 ` RISC-V Zbb QEMU Boot Failures (was Re: [PATCH v1] RISC-V: take text_mutex during alternative patching) Palmer Dabbelt 1 sibling, 1 reply; 20+ messages in thread From: Andrew Jones @ 2023-02-22 15:31 UTC (permalink / raw) To: Guenter Roeck Cc: Heiko Stübner, Conor Dooley, palmer, Conor Dooley, samuel, linux-riscv On Wed, Feb 22, 2023 at 03:27:43PM +0100, Andrew Jones wrote: > On Thu, Feb 16, 2023 at 07:33:55AM -0800, Guenter Roeck wrote: > > On 2/15/23 14:00, Heiko Stübner wrote: > > [ ... ] > > > > > > So now I've also tested Palmer's for-next at > > > commit ec6311919ea6 ("Merge patch series "riscv: Optimize function trace"") > > > > > > again with the same variants > > > - qemu-riscv32 without zbb > > > - qemu-riscv32 with zbb > > > - qemu-riscv64 without zbb > > > - qemu-riscv64 with zbb > > > > > > And all of them booted fine into a nfs-root (debian for riscv64 and a > > > buildroot for riscv32). > > > > > > I even forced a bug into the zbb code to make sure the patching worked > > > correctly (where the kernel failed as expected). > > > > > > Qemu-version for me was 7.2.50 (v7.2.0-744-g5a3633929a-dirty) > > > > > > I did try the one from Debian-stable (qemu-5.2) but that was too old and > > > didn't support Zbb yet. > > > > > > One thing of note, the "active" 32bit config I had, somehow didn't produce > > > working images and I needed to start a new build using the rv32_defconfig. > > > > > > So right now, I'm not sure what more to test though. > > > > > > > Another example: > > > > - build defconfig > > - run > > qemu-system-riscv64 -M virt -m 512M -no-reboot -kernel arch/riscv/boot/Image \ > > -snapshot -device virtio-blk-device,drive=d0 -drive file=rootfs.ext2,if=none,id=d0,format=raw \ > > -append "root=/dev/vda console=ttyS0,115200 earlycon=uart8250,mmio,0x10000000,115200" \ > > -nographic -monitor none > > > > With CONFIG_RISCV_ISA_ZBB=y, that results in > > > > [ 0.818263] /dev/root: Can't open blockdev > > [ 0.818856] VFS: Cannot open root device "/dev/vda" or unknown-block(0,0): error -6 > > [ 0.819177] Please append a correct "root=" boot option; here are the available partitions: > > [ 0.819808] fe00 16384 vda > > [ 0.819944] driver: virtio_blk > > [ 0.820534] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) > > [ 0.821101] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.2.0-rc8-next-20230216-00002-g80332825e240 #4 > > [ 0.821672] Hardware name: riscv-virtio,qemu (DT) > > [ 0.822050] Call Trace: > > [ 0.822427] [<ffffffff800053e4>] dump_backtrace+0x1c/0x24 > > [ 0.822834] [<ffffffff807f90e4>] show_stack+0x2c/0x38 > > [ 0.823085] [<ffffffff80803aea>] dump_stack_lvl+0x3c/0x54 > > [ 0.823351] [<ffffffff80803b16>] dump_stack+0x14/0x1c > > [ 0.823601] [<ffffffff807f944c>] panic+0x102/0x29e > > [ 0.823834] [<ffffffff80a015e2>] mount_block_root+0x18c/0x23e > > [ 0.824148] [<ffffffff80a0187c>] mount_root+0x1e8/0x218 > > [ 0.824398] [<ffffffff80a019ee>] prepare_namespace+0x142/0x184 > > [ 0.824655] [<ffffffff80a01182>] kernel_init_freeable+0x236/0x25a > > [ 0.824934] [<ffffffff80804602>] kernel_init+0x1e/0x10a > > [ 0.825201] [<ffffffff80003560>] ret_from_exception+0x0/0x16 > > [ 0.826180] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]--- > > > > This works fine if CONFIG_RISCV_ISA_ZBB is not enabled. > > > > Tested with gcc 11.3, binutils 2.39, qemu v7.2.0 and qemu built from mainline. > > > > Just to +1 this, I get the same result (unable to mount root fs) with > > $QEMU -cpu rv64,zbb=on \ > -nographic \ > -machine virt \ > -kernel $KERNEL \ > -append 'root=/dev/vda console=ttyS0' \ > -drive file=disk.ext4,format=raw,id=hd0 \ > -device virtio-blk-pci,drive=hd0 > > kernel: latest riscv-linux/for-next (8658db0a4a0f), defconfig > gcc: riscv-gnu-toolchain (12.1.0) > binutils: riscv-gnu-toolchain (2.39) > qemu: latest master (79b677d658d3) > > Flipping the QEMU cpu zbb property off allows boot to succeed, i.e. it's > not necessary to compile out the CONFIG_RISCV_ISA_ZBB code from the > kernel, it's just necessary to avoid using it. > Looks like something in the strncmp implementation. Only commenting it out allows boot to succeed. diff --git a/arch/riscv/lib/strncmp.S b/arch/riscv/lib/strncmp.S index ee49595075be..0bf03abe1ced 100644 --- a/arch/riscv/lib/strncmp.S +++ b/arch/riscv/lib/strncmp.S @@ -9,7 +9,7 @@ /* int strncmp(const char *cs, const char *ct, size_t count) */ SYM_FUNC_START(strncmp) - ALTERNATIVE("nop", "j strncmp_zbb", 0, RISCV_ISA_EXT_ZBB, CONFIG_RISCV_ISA_ZBB) +// ALTERNATIVE("nop", "j strncmp_zbb", 0, RISCV_ISA_EXT_ZBB, CONFIG_RISCV_ISA_ZBB) /* * Returns Thanks, drew _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH v1] RISC-V: take text_mutex during alternative patching 2023-02-22 15:31 ` Andrew Jones @ 2023-02-22 15:39 ` Heiko Stübner 2023-02-22 16:47 ` Palmer Dabbelt 0 siblings, 1 reply; 20+ messages in thread From: Heiko Stübner @ 2023-02-22 15:39 UTC (permalink / raw) To: Guenter Roeck, Andrew Jones Cc: Conor Dooley, palmer, Conor Dooley, samuel, linux-riscv Am Mittwoch, 22. Februar 2023, 16:31:25 CET schrieb Andrew Jones: > On Wed, Feb 22, 2023 at 03:27:43PM +0100, Andrew Jones wrote: > > On Thu, Feb 16, 2023 at 07:33:55AM -0800, Guenter Roeck wrote: > > > On 2/15/23 14:00, Heiko Stübner wrote: > > > [ ... ] > > > > > > > > So now I've also tested Palmer's for-next at > > > > commit ec6311919ea6 ("Merge patch series "riscv: Optimize function trace"") > > > > > > > > again with the same variants > > > > - qemu-riscv32 without zbb > > > > - qemu-riscv32 with zbb > > > > - qemu-riscv64 without zbb > > > > - qemu-riscv64 with zbb > > > > > > > > And all of them booted fine into a nfs-root (debian for riscv64 and a > > > > buildroot for riscv32). > > > > > > > > I even forced a bug into the zbb code to make sure the patching worked > > > > correctly (where the kernel failed as expected). > > > > > > > > Qemu-version for me was 7.2.50 (v7.2.0-744-g5a3633929a-dirty) > > > > > > > > I did try the one from Debian-stable (qemu-5.2) but that was too old and > > > > didn't support Zbb yet. > > > > > > > > One thing of note, the "active" 32bit config I had, somehow didn't produce > > > > working images and I needed to start a new build using the rv32_defconfig. > > > > > > > > So right now, I'm not sure what more to test though. > > > > > > > > > > Another example: > > > > > > - build defconfig > > > - run > > > qemu-system-riscv64 -M virt -m 512M -no-reboot -kernel arch/riscv/boot/Image \ > > > -snapshot -device virtio-blk-device,drive=d0 -drive file=rootfs.ext2,if=none,id=d0,format=raw \ > > > -append "root=/dev/vda console=ttyS0,115200 earlycon=uart8250,mmio,0x10000000,115200" \ > > > -nographic -monitor none > > > > > > With CONFIG_RISCV_ISA_ZBB=y, that results in > > > > > > [ 0.818263] /dev/root: Can't open blockdev > > > [ 0.818856] VFS: Cannot open root device "/dev/vda" or unknown-block(0,0): error -6 > > > [ 0.819177] Please append a correct "root=" boot option; here are the available partitions: > > > [ 0.819808] fe00 16384 vda > > > [ 0.819944] driver: virtio_blk > > > [ 0.820534] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) > > > [ 0.821101] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.2.0-rc8-next-20230216-00002-g80332825e240 #4 > > > [ 0.821672] Hardware name: riscv-virtio,qemu (DT) > > > [ 0.822050] Call Trace: > > > [ 0.822427] [<ffffffff800053e4>] dump_backtrace+0x1c/0x24 > > > [ 0.822834] [<ffffffff807f90e4>] show_stack+0x2c/0x38 > > > [ 0.823085] [<ffffffff80803aea>] dump_stack_lvl+0x3c/0x54 > > > [ 0.823351] [<ffffffff80803b16>] dump_stack+0x14/0x1c > > > [ 0.823601] [<ffffffff807f944c>] panic+0x102/0x29e > > > [ 0.823834] [<ffffffff80a015e2>] mount_block_root+0x18c/0x23e > > > [ 0.824148] [<ffffffff80a0187c>] mount_root+0x1e8/0x218 > > > [ 0.824398] [<ffffffff80a019ee>] prepare_namespace+0x142/0x184 > > > [ 0.824655] [<ffffffff80a01182>] kernel_init_freeable+0x236/0x25a > > > [ 0.824934] [<ffffffff80804602>] kernel_init+0x1e/0x10a > > > [ 0.825201] [<ffffffff80003560>] ret_from_exception+0x0/0x16 > > > [ 0.826180] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]--- > > > > > > This works fine if CONFIG_RISCV_ISA_ZBB is not enabled. > > > > > > Tested with gcc 11.3, binutils 2.39, qemu v7.2.0 and qemu built from mainline. > > > > > > > Just to +1 this, I get the same result (unable to mount root fs) with > > > > $QEMU -cpu rv64,zbb=on \ > > -nographic \ > > -machine virt \ > > -kernel $KERNEL \ > > -append 'root=/dev/vda console=ttyS0' \ > > -drive file=disk.ext4,format=raw,id=hd0 \ > > -device virtio-blk-pci,drive=hd0 > > > > kernel: latest riscv-linux/for-next (8658db0a4a0f), defconfig > > gcc: riscv-gnu-toolchain (12.1.0) > > binutils: riscv-gnu-toolchain (2.39) > > qemu: latest master (79b677d658d3) > > > > Flipping the QEMU cpu zbb property off allows boot to succeed, i.e. it's > > not necessary to compile out the CONFIG_RISCV_ISA_ZBB code from the > > kernel, it's just necessary to avoid using it. > > > > Looks like something in the strncmp implementation. Only commenting it > out allows boot to succeed. and interestingly it seems to be something very specific. I.e. my setup is nfsroot-based (qemu is "just" another board in my boardfarm) and booting into an nfs-root works quite nicely. I guess I need to look into how to get an actual disk-image in there. > diff --git a/arch/riscv/lib/strncmp.S b/arch/riscv/lib/strncmp.S > index ee49595075be..0bf03abe1ced 100644 > --- a/arch/riscv/lib/strncmp.S > +++ b/arch/riscv/lib/strncmp.S > @@ -9,7 +9,7 @@ > /* int strncmp(const char *cs, const char *ct, size_t count) */ > SYM_FUNC_START(strncmp) > > - ALTERNATIVE("nop", "j strncmp_zbb", 0, RISCV_ISA_EXT_ZBB, CONFIG_RISCV_ISA_ZBB) > +// ALTERNATIVE("nop", "j strncmp_zbb", 0, RISCV_ISA_EXT_ZBB, CONFIG_RISCV_ISA_ZBB) > > /* > * Returns > > > Thanks, > drew > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v1] RISC-V: take text_mutex during alternative patching 2023-02-22 15:39 ` Heiko Stübner @ 2023-02-22 16:47 ` Palmer Dabbelt 2023-02-22 17:03 ` Heiko Stübner 0 siblings, 1 reply; 20+ messages in thread From: Palmer Dabbelt @ 2023-02-22 16:47 UTC (permalink / raw) To: heiko; +Cc: linux, ajones, Conor Dooley, Conor Dooley, samuel, linux-riscv On Wed, 22 Feb 2023 07:39:11 PST (-0800), heiko@sntech.de wrote: > Am Mittwoch, 22. Februar 2023, 16:31:25 CET schrieb Andrew Jones: >> On Wed, Feb 22, 2023 at 03:27:43PM +0100, Andrew Jones wrote: >> > On Thu, Feb 16, 2023 at 07:33:55AM -0800, Guenter Roeck wrote: >> > > On 2/15/23 14:00, Heiko Stübner wrote: >> > > [ ... ] >> > > > >> > > > So now I've also tested Palmer's for-next at >> > > > commit ec6311919ea6 ("Merge patch series "riscv: Optimize function trace"") >> > > > >> > > > again with the same variants >> > > > - qemu-riscv32 without zbb >> > > > - qemu-riscv32 with zbb >> > > > - qemu-riscv64 without zbb >> > > > - qemu-riscv64 with zbb >> > > > >> > > > And all of them booted fine into a nfs-root (debian for riscv64 and a >> > > > buildroot for riscv32). >> > > > >> > > > I even forced a bug into the zbb code to make sure the patching worked >> > > > correctly (where the kernel failed as expected). >> > > > >> > > > Qemu-version for me was 7.2.50 (v7.2.0-744-g5a3633929a-dirty) >> > > > >> > > > I did try the one from Debian-stable (qemu-5.2) but that was too old and >> > > > didn't support Zbb yet. >> > > > >> > > > One thing of note, the "active" 32bit config I had, somehow didn't produce >> > > > working images and I needed to start a new build using the rv32_defconfig. >> > > > >> > > > So right now, I'm not sure what more to test though. >> > > > >> > > >> > > Another example: >> > > >> > > - build defconfig >> > > - run >> > > qemu-system-riscv64 -M virt -m 512M -no-reboot -kernel arch/riscv/boot/Image \ >> > > -snapshot -device virtio-blk-device,drive=d0 -drive file=rootfs.ext2,if=none,id=d0,format=raw \ >> > > -append "root=/dev/vda console=ttyS0,115200 earlycon=uart8250,mmio,0x10000000,115200" \ >> > > -nographic -monitor none >> > > >> > > With CONFIG_RISCV_ISA_ZBB=y, that results in >> > > >> > > [ 0.818263] /dev/root: Can't open blockdev >> > > [ 0.818856] VFS: Cannot open root device "/dev/vda" or unknown-block(0,0): error -6 >> > > [ 0.819177] Please append a correct "root=" boot option; here are the available partitions: >> > > [ 0.819808] fe00 16384 vda >> > > [ 0.819944] driver: virtio_blk >> > > [ 0.820534] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) >> > > [ 0.821101] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.2.0-rc8-next-20230216-00002-g80332825e240 #4 >> > > [ 0.821672] Hardware name: riscv-virtio,qemu (DT) >> > > [ 0.822050] Call Trace: >> > > [ 0.822427] [<ffffffff800053e4>] dump_backtrace+0x1c/0x24 >> > > [ 0.822834] [<ffffffff807f90e4>] show_stack+0x2c/0x38 >> > > [ 0.823085] [<ffffffff80803aea>] dump_stack_lvl+0x3c/0x54 >> > > [ 0.823351] [<ffffffff80803b16>] dump_stack+0x14/0x1c >> > > [ 0.823601] [<ffffffff807f944c>] panic+0x102/0x29e >> > > [ 0.823834] [<ffffffff80a015e2>] mount_block_root+0x18c/0x23e >> > > [ 0.824148] [<ffffffff80a0187c>] mount_root+0x1e8/0x218 >> > > [ 0.824398] [<ffffffff80a019ee>] prepare_namespace+0x142/0x184 >> > > [ 0.824655] [<ffffffff80a01182>] kernel_init_freeable+0x236/0x25a >> > > [ 0.824934] [<ffffffff80804602>] kernel_init+0x1e/0x10a >> > > [ 0.825201] [<ffffffff80003560>] ret_from_exception+0x0/0x16 >> > > [ 0.826180] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]--- >> > > >> > > This works fine if CONFIG_RISCV_ISA_ZBB is not enabled. >> > > >> > > Tested with gcc 11.3, binutils 2.39, qemu v7.2.0 and qemu built from mainline. >> > > >> > >> > Just to +1 this, I get the same result (unable to mount root fs) with >> > >> > $QEMU -cpu rv64,zbb=on \ >> > -nographic \ >> > -machine virt \ >> > -kernel $KERNEL \ >> > -append 'root=/dev/vda console=ttyS0' \ >> > -drive file=disk.ext4,format=raw,id=hd0 \ >> > -device virtio-blk-pci,drive=hd0 >> > >> > kernel: latest riscv-linux/for-next (8658db0a4a0f), defconfig >> > gcc: riscv-gnu-toolchain (12.1.0) >> > binutils: riscv-gnu-toolchain (2.39) >> > qemu: latest master (79b677d658d3) >> > >> > Flipping the QEMU cpu zbb property off allows boot to succeed, i.e. it's >> > not necessary to compile out the CONFIG_RISCV_ISA_ZBB code from the >> > kernel, it's just necessary to avoid using it. >> > >> >> Looks like something in the strncmp implementation. Only commenting it >> out allows boot to succeed. > > and interestingly it seems to be something very specific. I.e. my setup is > nfsroot-based (qemu is "just" another board in my boardfarm) and booting > into an nfs-root works quite nicely. > > I guess I need to look into how to get an actual disk-image in there. It looks like Drew isn't using an initrd (and with NFS, presumably you are)? That's probably a big difference as well. > > >> diff --git a/arch/riscv/lib/strncmp.S b/arch/riscv/lib/strncmp.S >> index ee49595075be..0bf03abe1ced 100644 >> --- a/arch/riscv/lib/strncmp.S >> +++ b/arch/riscv/lib/strncmp.S >> @@ -9,7 +9,7 @@ >> /* int strncmp(const char *cs, const char *ct, size_t count) */ >> SYM_FUNC_START(strncmp) >> >> - ALTERNATIVE("nop", "j strncmp_zbb", 0, RISCV_ISA_EXT_ZBB, CONFIG_RISCV_ISA_ZBB) >> +// ALTERNATIVE("nop", "j strncmp_zbb", 0, RISCV_ISA_EXT_ZBB, CONFIG_RISCV_ISA_ZBB) >> >> /* >> * Returns >> >> >> Thanks, >> drew >> > > > > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v1] RISC-V: take text_mutex during alternative patching 2023-02-22 16:47 ` Palmer Dabbelt @ 2023-02-22 17:03 ` Heiko Stübner 2023-02-22 17:43 ` Heiko Stübner 0 siblings, 1 reply; 20+ messages in thread From: Heiko Stübner @ 2023-02-22 17:03 UTC (permalink / raw) To: Palmer Dabbelt Cc: linux, ajones, Conor Dooley, Conor Dooley, samuel, linux-riscv Am Mittwoch, 22. Februar 2023, 17:47:10 CET schrieb Palmer Dabbelt: > On Wed, 22 Feb 2023 07:39:11 PST (-0800), heiko@sntech.de wrote: > > Am Mittwoch, 22. Februar 2023, 16:31:25 CET schrieb Andrew Jones: > >> On Wed, Feb 22, 2023 at 03:27:43PM +0100, Andrew Jones wrote: > >> > On Thu, Feb 16, 2023 at 07:33:55AM -0800, Guenter Roeck wrote: > >> > > On 2/15/23 14:00, Heiko Stübner wrote: > >> > > [ ... ] > >> > > > > >> > > > So now I've also tested Palmer's for-next at > >> > > > commit ec6311919ea6 ("Merge patch series "riscv: Optimize function trace"") > >> > > > > >> > > > again with the same variants > >> > > > - qemu-riscv32 without zbb > >> > > > - qemu-riscv32 with zbb > >> > > > - qemu-riscv64 without zbb > >> > > > - qemu-riscv64 with zbb > >> > > > > >> > > > And all of them booted fine into a nfs-root (debian for riscv64 and a > >> > > > buildroot for riscv32). > >> > > > > >> > > > I even forced a bug into the zbb code to make sure the patching worked > >> > > > correctly (where the kernel failed as expected). > >> > > > > >> > > > Qemu-version for me was 7.2.50 (v7.2.0-744-g5a3633929a-dirty) > >> > > > > >> > > > I did try the one from Debian-stable (qemu-5.2) but that was too old and > >> > > > didn't support Zbb yet. > >> > > > > >> > > > One thing of note, the "active" 32bit config I had, somehow didn't produce > >> > > > working images and I needed to start a new build using the rv32_defconfig. > >> > > > > >> > > > So right now, I'm not sure what more to test though. > >> > > > > >> > > > >> > > Another example: > >> > > > >> > > - build defconfig > >> > > - run > >> > > qemu-system-riscv64 -M virt -m 512M -no-reboot -kernel arch/riscv/boot/Image \ > >> > > -snapshot -device virtio-blk-device,drive=d0 -drive file=rootfs.ext2,if=none,id=d0,format=raw \ > >> > > -append "root=/dev/vda console=ttyS0,115200 earlycon=uart8250,mmio,0x10000000,115200" \ > >> > > -nographic -monitor none > >> > > > >> > > With CONFIG_RISCV_ISA_ZBB=y, that results in > >> > > > >> > > [ 0.818263] /dev/root: Can't open blockdev > >> > > [ 0.818856] VFS: Cannot open root device "/dev/vda" or unknown-block(0,0): error -6 > >> > > [ 0.819177] Please append a correct "root=" boot option; here are the available partitions: > >> > > [ 0.819808] fe00 16384 vda > >> > > [ 0.819944] driver: virtio_blk > >> > > [ 0.820534] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) > >> > > [ 0.821101] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.2.0-rc8-next-20230216-00002-g80332825e240 #4 > >> > > [ 0.821672] Hardware name: riscv-virtio,qemu (DT) > >> > > [ 0.822050] Call Trace: > >> > > [ 0.822427] [<ffffffff800053e4>] dump_backtrace+0x1c/0x24 > >> > > [ 0.822834] [<ffffffff807f90e4>] show_stack+0x2c/0x38 > >> > > [ 0.823085] [<ffffffff80803aea>] dump_stack_lvl+0x3c/0x54 > >> > > [ 0.823351] [<ffffffff80803b16>] dump_stack+0x14/0x1c > >> > > [ 0.823601] [<ffffffff807f944c>] panic+0x102/0x29e > >> > > [ 0.823834] [<ffffffff80a015e2>] mount_block_root+0x18c/0x23e > >> > > [ 0.824148] [<ffffffff80a0187c>] mount_root+0x1e8/0x218 > >> > > [ 0.824398] [<ffffffff80a019ee>] prepare_namespace+0x142/0x184 > >> > > [ 0.824655] [<ffffffff80a01182>] kernel_init_freeable+0x236/0x25a > >> > > [ 0.824934] [<ffffffff80804602>] kernel_init+0x1e/0x10a > >> > > [ 0.825201] [<ffffffff80003560>] ret_from_exception+0x0/0x16 > >> > > [ 0.826180] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]--- > >> > > > >> > > This works fine if CONFIG_RISCV_ISA_ZBB is not enabled. > >> > > > >> > > Tested with gcc 11.3, binutils 2.39, qemu v7.2.0 and qemu built from mainline. > >> > > > >> > > >> > Just to +1 this, I get the same result (unable to mount root fs) with > >> > > >> > $QEMU -cpu rv64,zbb=on \ > >> > -nographic \ > >> > -machine virt \ > >> > -kernel $KERNEL \ > >> > -append 'root=/dev/vda console=ttyS0' \ > >> > -drive file=disk.ext4,format=raw,id=hd0 \ > >> > -device virtio-blk-pci,drive=hd0 > >> > > >> > kernel: latest riscv-linux/for-next (8658db0a4a0f), defconfig > >> > gcc: riscv-gnu-toolchain (12.1.0) > >> > binutils: riscv-gnu-toolchain (2.39) > >> > qemu: latest master (79b677d658d3) > >> > > >> > Flipping the QEMU cpu zbb property off allows boot to succeed, i.e. it's > >> > not necessary to compile out the CONFIG_RISCV_ISA_ZBB code from the > >> > kernel, it's just necessary to avoid using it. > >> > > >> > >> Looks like something in the strncmp implementation. Only commenting it > >> out allows boot to succeed. > > > > and interestingly it seems to be something very specific. I.e. my setup is > > nfsroot-based (qemu is "just" another board in my boardfarm) and booting > > into an nfs-root works quite nicely. > > > > I guess I need to look into how to get an actual disk-image in there. > > It looks like Drew isn't using an initrd (and with NFS, presumably you > are)? That's probably a big difference as well. There is no initrd involved in my qemu setup ;-) . Just a kernel built from current for-next + defconfig and a nfs-server holding a full Debian-riscv64 system. The magic qemu incantation is also pretty standard: /usr/local/bin/qemu-system-riscv64 -M virt -smp 2 -m 1G -display none \ -cpu rv64,zbb=true,zbc=true,svpbmt=true,Zicbom=true,Zawrs=true,sscofpmf=true,v=true \ -serial telnet:localhost:5500,server,nowait -kernel /home/devel/nfs/kernel/riscv64/Image \ -append earlycon=sbi root=/dev/nfs nfsroot=10.0.2.2:/home/devel/nfs/rootfs-riscv64virt ip=dhcp rw \ -netdev user,id=n1 -device virtio-net-pci,netdev=n1 -name boardfarm-0,process=boardfarm-vm-0 -daemonize And I also checked that my kernel really lands in the Zbb-code by simply adding a "ret" [0] and making sure it breaks vs. runs without it Next I'll try to move my rootfs into a real image-file and switch over to the commandline Drew calls, to see if it'll reproduce then. [0] diff --git a/arch/riscv/lib/strncmp.S b/arch/riscv/lib/strncmp.S index ee49595075be..6b35933c5949 100644 --- a/arch/riscv/lib/strncmp.S +++ b/arch/riscv/lib/strncmp.S @@ -53,6 +53,7 @@ strncmp_zbb: .option push .option arch,+zbb + ret /* * Returns * a0 - comparison result, like strncmp _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH v1] RISC-V: take text_mutex during alternative patching 2023-02-22 17:03 ` Heiko Stübner @ 2023-02-22 17:43 ` Heiko Stübner 2023-02-22 19:06 ` Guenter Roeck 0 siblings, 1 reply; 20+ messages in thread From: Heiko Stübner @ 2023-02-22 17:43 UTC (permalink / raw) To: Palmer Dabbelt Cc: linux, ajones, Conor Dooley, Conor Dooley, samuel, linux-riscv, christoph.muellner Am Mittwoch, 22. Februar 2023, 18:03:55 CET schrieb Heiko Stübner: > Am Mittwoch, 22. Februar 2023, 17:47:10 CET schrieb Palmer Dabbelt: > > On Wed, 22 Feb 2023 07:39:11 PST (-0800), heiko@sntech.de wrote: > > > Am Mittwoch, 22. Februar 2023, 16:31:25 CET schrieb Andrew Jones: > > >> On Wed, Feb 22, 2023 at 03:27:43PM +0100, Andrew Jones wrote: > > >> > On Thu, Feb 16, 2023 at 07:33:55AM -0800, Guenter Roeck wrote: > > >> > > On 2/15/23 14:00, Heiko Stübner wrote: > > >> > > [ ... ] > > >> > > > > > >> > > > So now I've also tested Palmer's for-next at > > >> > > > commit ec6311919ea6 ("Merge patch series "riscv: Optimize function trace"") > > >> > > > > > >> > > > again with the same variants > > >> > > > - qemu-riscv32 without zbb > > >> > > > - qemu-riscv32 with zbb > > >> > > > - qemu-riscv64 without zbb > > >> > > > - qemu-riscv64 with zbb > > >> > > > > > >> > > > And all of them booted fine into a nfs-root (debian for riscv64 and a > > >> > > > buildroot for riscv32). > > >> > > > > > >> > > > I even forced a bug into the zbb code to make sure the patching worked > > >> > > > correctly (where the kernel failed as expected). > > >> > > > > > >> > > > Qemu-version for me was 7.2.50 (v7.2.0-744-g5a3633929a-dirty) > > >> > > > > > >> > > > I did try the one from Debian-stable (qemu-5.2) but that was too old and > > >> > > > didn't support Zbb yet. > > >> > > > > > >> > > > One thing of note, the "active" 32bit config I had, somehow didn't produce > > >> > > > working images and I needed to start a new build using the rv32_defconfig. > > >> > > > > > >> > > > So right now, I'm not sure what more to test though. > > >> > > > > > >> > > > > >> > > Another example: > > >> > > > > >> > > - build defconfig > > >> > > - run > > >> > > qemu-system-riscv64 -M virt -m 512M -no-reboot -kernel arch/riscv/boot/Image \ > > >> > > -snapshot -device virtio-blk-device,drive=d0 -drive file=rootfs.ext2,if=none,id=d0,format=raw \ > > >> > > -append "root=/dev/vda console=ttyS0,115200 earlycon=uart8250,mmio,0x10000000,115200" \ > > >> > > -nographic -monitor none > > >> > > > > >> > > With CONFIG_RISCV_ISA_ZBB=y, that results in > > >> > > > > >> > > [ 0.818263] /dev/root: Can't open blockdev > > >> > > [ 0.818856] VFS: Cannot open root device "/dev/vda" or unknown-block(0,0): error -6 > > >> > > [ 0.819177] Please append a correct "root=" boot option; here are the available partitions: > > >> > > [ 0.819808] fe00 16384 vda > > >> > > [ 0.819944] driver: virtio_blk > > >> > > [ 0.820534] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) > > >> > > [ 0.821101] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.2.0-rc8-next-20230216-00002-g80332825e240 #4 > > >> > > [ 0.821672] Hardware name: riscv-virtio,qemu (DT) > > >> > > [ 0.822050] Call Trace: > > >> > > [ 0.822427] [<ffffffff800053e4>] dump_backtrace+0x1c/0x24 > > >> > > [ 0.822834] [<ffffffff807f90e4>] show_stack+0x2c/0x38 > > >> > > [ 0.823085] [<ffffffff80803aea>] dump_stack_lvl+0x3c/0x54 > > >> > > [ 0.823351] [<ffffffff80803b16>] dump_stack+0x14/0x1c > > >> > > [ 0.823601] [<ffffffff807f944c>] panic+0x102/0x29e > > >> > > [ 0.823834] [<ffffffff80a015e2>] mount_block_root+0x18c/0x23e > > >> > > [ 0.824148] [<ffffffff80a0187c>] mount_root+0x1e8/0x218 > > >> > > [ 0.824398] [<ffffffff80a019ee>] prepare_namespace+0x142/0x184 > > >> > > [ 0.824655] [<ffffffff80a01182>] kernel_init_freeable+0x236/0x25a > > >> > > [ 0.824934] [<ffffffff80804602>] kernel_init+0x1e/0x10a > > >> > > [ 0.825201] [<ffffffff80003560>] ret_from_exception+0x0/0x16 > > >> > > [ 0.826180] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]--- > > >> > > > > >> > > This works fine if CONFIG_RISCV_ISA_ZBB is not enabled. > > >> > > > > >> > > Tested with gcc 11.3, binutils 2.39, qemu v7.2.0 and qemu built from mainline. > > >> > > > > >> > > > >> > Just to +1 this, I get the same result (unable to mount root fs) with > > >> > > > >> > $QEMU -cpu rv64,zbb=on \ > > >> > -nographic \ > > >> > -machine virt \ > > >> > -kernel $KERNEL \ > > >> > -append 'root=/dev/vda console=ttyS0' \ > > >> > -drive file=disk.ext4,format=raw,id=hd0 \ > > >> > -device virtio-blk-pci,drive=hd0 > > >> > > > >> > kernel: latest riscv-linux/for-next (8658db0a4a0f), defconfig > > >> > gcc: riscv-gnu-toolchain (12.1.0) > > >> > binutils: riscv-gnu-toolchain (2.39) > > >> > qemu: latest master (79b677d658d3) > > >> > > > >> > Flipping the QEMU cpu zbb property off allows boot to succeed, i.e. it's > > >> > not necessary to compile out the CONFIG_RISCV_ISA_ZBB code from the > > >> > kernel, it's just necessary to avoid using it. > > >> > > > >> > > >> Looks like something in the strncmp implementation. Only commenting it > > >> out allows boot to succeed. > > > > > > and interestingly it seems to be something very specific. I.e. my setup is > > > nfsroot-based (qemu is "just" another board in my boardfarm) and booting > > > into an nfs-root works quite nicely. > > > > > > I guess I need to look into how to get an actual disk-image in there. > > > > It looks like Drew isn't using an initrd (and with NFS, presumably you > > are)? That's probably a big difference as well. > > There is no initrd involved in my qemu setup ;-) . > Just a kernel built from current for-next + defconfig and a nfs-server > holding a full Debian-riscv64 system. > > > The magic qemu incantation is also pretty standard: > > /usr/local/bin/qemu-system-riscv64 -M virt -smp 2 -m 1G -display none \ > -cpu rv64,zbb=true,zbc=true,svpbmt=true,Zicbom=true,Zawrs=true,sscofpmf=true,v=true \ > -serial telnet:localhost:5500,server,nowait -kernel /home/devel/nfs/kernel/riscv64/Image \ > -append earlycon=sbi root=/dev/nfs nfsroot=10.0.2.2:/home/devel/nfs/rootfs-riscv64virt ip=dhcp rw \ > -netdev user,id=n1 -device virtio-net-pci,netdev=n1 -name boardfarm-0,process=boardfarm-vm-0 -daemonize > > > And I also checked that my kernel really lands in the Zbb-code by simply > adding a "ret" [0] and making sure it breaks vs. runs without it > > > Next I'll try to move my rootfs into a real image-file and switch over to > the commandline Drew calls, to see if it'll reproduce then. With the rootfs in an image I could reproduce the issue now. I hacked in a very crude change to find the invocation that acts differently and voila it's a strncmp of the "/dev/vda" against "/dev/" [0]. It's really strange that all the other invocations produce correct results. [0] non-working - with zbb-strncmp: [ 2.619129] strncmp: comparing /dev/vda <-> mtd, count 3 => -1 [ 2.620451] strncmp: comparing /dev/vda <-> ubi, count 3 => -1 [ 2.621163] strncmp: comparing /dev/vda <-> PARTUUID=, count 9 => -1 [ 2.621703] strncmp: comparing /dev/vda <-> PARTLABEL=, count 10 => -1 ------ below is the difference [ 2.622255] strncmp: comparing /dev/vda <-> /dev/, count 5 => 1 [ 2.623446] strncmp: comparing /dev/vda <-> /dev/, count 5 => 1 ------ above is the difference [ 2.627064] strncmp: comparing sysfs <-> ext3, count 4 => 14 [ 2.627646] strncmp: comparing tmpfs <-> ext3, count 4 => 15 [ 2.628476] strncmp: comparing bdev <-> ext3, count 4 => -3 [ 2.628990] strncmp: comparing proc <-> ext3, count 4 => 11 [ 2.629422] strncmp: comparing cgroup <-> ext3, count 4 => -2 [ 2.629856] strncmp: comparing cgroup2 <-> ext3, count 4 => -2 [ 2.630345] strncmp: comparing cpuset <-> ext3, count 4 => -2 [ 2.630785] strncmp: comparing devtmpfs <-> ext3, count 4 => -1 [ 2.631267] strncmp: comparing debugfs <-> ext3, count 4 => -1 [ 2.631696] strncmp: comparing securityfs <-> ext3, count 4 => 1 [ 2.632596] strncmp: comparing sockfs <-> ext3, count 4 => 14 [ 2.633095] strncmp: comparing bpf <-> ext3, count 4 => -3 [ 2.633600] strncmp: comparing pipefs <-> ext3, count 4 => 11 [ 2.634071] strncmp: comparing ramfs <-> ext3, count 4 => 13 [ 2.634501] strncmp: comparing hugetlbfs <-> ext3, count 4 => 1 [ 2.634955] strncmp: comparing rpc_pipefs <-> ext3, count 4 => 1 [ 2.635407] strncmp: comparing devpts <-> ext3, count 4 => -1 [ 2.638788] strncmp: comparing ext3 <-> ext3, count 4 => 0 working - with normal strncmp: [ 2.416438] strncmp: comparing /dev/vda <-> mtd, count 3 => -62 [ 2.417312] strncmp: comparing /dev/vda <-> ubi, count 3 => -70 [ 2.418296] strncmp: comparing /dev/vda <-> PARTUUID=, count 9 => -33 [ 2.418921] strncmp: comparing /dev/vda <-> PARTLABEL=, count 10 => -33 ------ below is the difference [ 2.419450] strncmp: comparing /dev/vda <-> /dev/, count 5 => 0 [ 2.420698] strncmp: comparing /dev/vda <-> /dev/, count 5 => 0 ------ above is the difference [ 2.424086] strncmp: comparing sysfs <-> ext3, count 4 => 14 [ 2.424663] strncmp: comparing tmpfs <-> ext3, count 4 => 15 [ 2.425111] strncmp: comparing bdev <-> ext3, count 4 => -3 [ 2.425563] strncmp: comparing proc <-> ext3, count 4 => 11 [ 2.426022] strncmp: comparing cgroup <-> ext3, count 4 => -2 [ 2.426717] strncmp: comparing cgroup2 <-> ext3, count 4 => -2 [ 2.427175] strncmp: comparing cpuset <-> ext3, count 4 => -2 [ 2.427608] strncmp: comparing devtmpfs <-> ext3, count 4 => -1 [ 2.428061] strncmp: comparing debugfs <-> ext3, count 4 => -1 [ 2.428526] strncmp: comparing securityfs <-> ext3, count 4 => 14 [ 2.428985] strncmp: comparing sockfs <-> ext3, count 4 => 14 [ 2.429423] strncmp: comparing bpf <-> ext3, count 4 => -3 [ 2.429863] strncmp: comparing pipefs <-> ext3, count 4 => 11 [ 2.430433] strncmp: comparing ramfs <-> ext3, count 4 => 13 [ 2.431202] strncmp: comparing hugetlbfs <-> ext3, count 4 => 3 [ 2.431721] strncmp: comparing rpc_pipefs <-> ext3, count 4 => 13 [ 2.432222] strncmp: comparing devpts <-> ext3, count 4 => -1 [ 2.432685] strncmp: comparing ext3 <-> ext3, count 4 => 0 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v1] RISC-V: take text_mutex during alternative patching 2023-02-22 17:43 ` Heiko Stübner @ 2023-02-22 19:06 ` Guenter Roeck 2023-02-22 20:33 ` Heiko Stübner 0 siblings, 1 reply; 20+ messages in thread From: Guenter Roeck @ 2023-02-22 19:06 UTC (permalink / raw) To: Heiko Stübner, Palmer Dabbelt Cc: ajones, Conor Dooley, Conor Dooley, samuel, linux-riscv, christoph.muellner On 2/22/23 09:43, Heiko Stübner wrote: > Am Mittwoch, 22. Februar 2023, 18:03:55 CET schrieb Heiko Stübner: >> Am Mittwoch, 22. Februar 2023, 17:47:10 CET schrieb Palmer Dabbelt: >>> On Wed, 22 Feb 2023 07:39:11 PST (-0800), heiko@sntech.de wrote: >>>> Am Mittwoch, 22. Februar 2023, 16:31:25 CET schrieb Andrew Jones: >>>>> On Wed, Feb 22, 2023 at 03:27:43PM +0100, Andrew Jones wrote: >>>>>> On Thu, Feb 16, 2023 at 07:33:55AM -0800, Guenter Roeck wrote: >>>>>>> On 2/15/23 14:00, Heiko Stübner wrote: >>>>>>> [ ... ] >>>>>>>> >>>>>>>> So now I've also tested Palmer's for-next at >>>>>>>> commit ec6311919ea6 ("Merge patch series "riscv: Optimize function trace"") >>>>>>>> >>>>>>>> again with the same variants >>>>>>>> - qemu-riscv32 without zbb >>>>>>>> - qemu-riscv32 with zbb >>>>>>>> - qemu-riscv64 without zbb >>>>>>>> - qemu-riscv64 with zbb >>>>>>>> >>>>>>>> And all of them booted fine into a nfs-root (debian for riscv64 and a >>>>>>>> buildroot for riscv32). >>>>>>>> >>>>>>>> I even forced a bug into the zbb code to make sure the patching worked >>>>>>>> correctly (where the kernel failed as expected). >>>>>>>> >>>>>>>> Qemu-version for me was 7.2.50 (v7.2.0-744-g5a3633929a-dirty) >>>>>>>> >>>>>>>> I did try the one from Debian-stable (qemu-5.2) but that was too old and >>>>>>>> didn't support Zbb yet. >>>>>>>> >>>>>>>> One thing of note, the "active" 32bit config I had, somehow didn't produce >>>>>>>> working images and I needed to start a new build using the rv32_defconfig. >>>>>>>> >>>>>>>> So right now, I'm not sure what more to test though. >>>>>>>> >>>>>>> >>>>>>> Another example: >>>>>>> >>>>>>> - build defconfig >>>>>>> - run >>>>>>> qemu-system-riscv64 -M virt -m 512M -no-reboot -kernel arch/riscv/boot/Image \ >>>>>>> -snapshot -device virtio-blk-device,drive=d0 -drive file=rootfs.ext2,if=none,id=d0,format=raw \ >>>>>>> -append "root=/dev/vda console=ttyS0,115200 earlycon=uart8250,mmio,0x10000000,115200" \ >>>>>>> -nographic -monitor none >>>>>>> >>>>>>> With CONFIG_RISCV_ISA_ZBB=y, that results in >>>>>>> >>>>>>> [ 0.818263] /dev/root: Can't open blockdev >>>>>>> [ 0.818856] VFS: Cannot open root device "/dev/vda" or unknown-block(0,0): error -6 >>>>>>> [ 0.819177] Please append a correct "root=" boot option; here are the available partitions: >>>>>>> [ 0.819808] fe00 16384 vda >>>>>>> [ 0.819944] driver: virtio_blk >>>>>>> [ 0.820534] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) >>>>>>> [ 0.821101] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.2.0-rc8-next-20230216-00002-g80332825e240 #4 >>>>>>> [ 0.821672] Hardware name: riscv-virtio,qemu (DT) >>>>>>> [ 0.822050] Call Trace: >>>>>>> [ 0.822427] [<ffffffff800053e4>] dump_backtrace+0x1c/0x24 >>>>>>> [ 0.822834] [<ffffffff807f90e4>] show_stack+0x2c/0x38 >>>>>>> [ 0.823085] [<ffffffff80803aea>] dump_stack_lvl+0x3c/0x54 >>>>>>> [ 0.823351] [<ffffffff80803b16>] dump_stack+0x14/0x1c >>>>>>> [ 0.823601] [<ffffffff807f944c>] panic+0x102/0x29e >>>>>>> [ 0.823834] [<ffffffff80a015e2>] mount_block_root+0x18c/0x23e >>>>>>> [ 0.824148] [<ffffffff80a0187c>] mount_root+0x1e8/0x218 >>>>>>> [ 0.824398] [<ffffffff80a019ee>] prepare_namespace+0x142/0x184 >>>>>>> [ 0.824655] [<ffffffff80a01182>] kernel_init_freeable+0x236/0x25a >>>>>>> [ 0.824934] [<ffffffff80804602>] kernel_init+0x1e/0x10a >>>>>>> [ 0.825201] [<ffffffff80003560>] ret_from_exception+0x0/0x16 >>>>>>> [ 0.826180] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]--- >>>>>>> >>>>>>> This works fine if CONFIG_RISCV_ISA_ZBB is not enabled. >>>>>>> >>>>>>> Tested with gcc 11.3, binutils 2.39, qemu v7.2.0 and qemu built from mainline. >>>>>>> >>>>>> >>>>>> Just to +1 this, I get the same result (unable to mount root fs) with >>>>>> >>>>>> $QEMU -cpu rv64,zbb=on \ >>>>>> -nographic \ >>>>>> -machine virt \ >>>>>> -kernel $KERNEL \ >>>>>> -append 'root=/dev/vda console=ttyS0' \ >>>>>> -drive file=disk.ext4,format=raw,id=hd0 \ >>>>>> -device virtio-blk-pci,drive=hd0 >>>>>> >>>>>> kernel: latest riscv-linux/for-next (8658db0a4a0f), defconfig >>>>>> gcc: riscv-gnu-toolchain (12.1.0) >>>>>> binutils: riscv-gnu-toolchain (2.39) >>>>>> qemu: latest master (79b677d658d3) >>>>>> >>>>>> Flipping the QEMU cpu zbb property off allows boot to succeed, i.e. it's >>>>>> not necessary to compile out the CONFIG_RISCV_ISA_ZBB code from the >>>>>> kernel, it's just necessary to avoid using it. >>>>>> >>>>> >>>>> Looks like something in the strncmp implementation. Only commenting it >>>>> out allows boot to succeed. >>>> >>>> and interestingly it seems to be something very specific. I.e. my setup is >>>> nfsroot-based (qemu is "just" another board in my boardfarm) and booting >>>> into an nfs-root works quite nicely. >>>> >>>> I guess I need to look into how to get an actual disk-image in there. >>> >>> It looks like Drew isn't using an initrd (and with NFS, presumably you >>> are)? That's probably a big difference as well. >> >> There is no initrd involved in my qemu setup ;-) . >> Just a kernel built from current for-next + defconfig and a nfs-server >> holding a full Debian-riscv64 system. >> >> >> The magic qemu incantation is also pretty standard: >> >> /usr/local/bin/qemu-system-riscv64 -M virt -smp 2 -m 1G -display none \ >> -cpu rv64,zbb=true,zbc=true,svpbmt=true,Zicbom=true,Zawrs=true,sscofpmf=true,v=true \ >> -serial telnet:localhost:5500,server,nowait -kernel /home/devel/nfs/kernel/riscv64/Image \ >> -append earlycon=sbi root=/dev/nfs nfsroot=10.0.2.2:/home/devel/nfs/rootfs-riscv64virt ip=dhcp rw \ >> -netdev user,id=n1 -device virtio-net-pci,netdev=n1 -name boardfarm-0,process=boardfarm-vm-0 -daemonize >> >> >> And I also checked that my kernel really lands in the Zbb-code by simply >> adding a "ret" [0] and making sure it breaks vs. runs without it >> >> >> Next I'll try to move my rootfs into a real image-file and switch over to >> the commandline Drew calls, to see if it'll reproduce then. > > With the rootfs in an image I could reproduce the issue now. > > I hacked in a very crude change to find the invocation that acts differently > and voila it's a strncmp of the "/dev/vda" against "/dev/" [0]. > > It's really strange that all the other invocations produce correct results. > Not really; the failures are the only comparisons which are expected to return 0 and are not a complete string match. I'd suspect that strncmp(s1, s2, strlen(s2)) will always return a bad result if s1 starts with s2 but is not identical to s2. Guenter > > > > [0] > non-working - with zbb-strncmp: > [ 2.619129] strncmp: comparing /dev/vda <-> mtd, count 3 => -1 > [ 2.620451] strncmp: comparing /dev/vda <-> ubi, count 3 => -1 > [ 2.621163] strncmp: comparing /dev/vda <-> PARTUUID=, count 9 => -1 > [ 2.621703] strncmp: comparing /dev/vda <-> PARTLABEL=, count 10 => -1 > ------ below is the difference > [ 2.622255] strncmp: comparing /dev/vda <-> /dev/, count 5 => 1 > [ 2.623446] strncmp: comparing /dev/vda <-> /dev/, count 5 => 1 > ------ above is the difference > [ 2.627064] strncmp: comparing sysfs <-> ext3, count 4 => 14 > [ 2.627646] strncmp: comparing tmpfs <-> ext3, count 4 => 15 > [ 2.628476] strncmp: comparing bdev <-> ext3, count 4 => -3 > [ 2.628990] strncmp: comparing proc <-> ext3, count 4 => 11 > [ 2.629422] strncmp: comparing cgroup <-> ext3, count 4 => -2 > [ 2.629856] strncmp: comparing cgroup2 <-> ext3, count 4 => -2 > [ 2.630345] strncmp: comparing cpuset <-> ext3, count 4 => -2 > [ 2.630785] strncmp: comparing devtmpfs <-> ext3, count 4 => -1 > [ 2.631267] strncmp: comparing debugfs <-> ext3, count 4 => -1 > [ 2.631696] strncmp: comparing securityfs <-> ext3, count 4 => 1 > [ 2.632596] strncmp: comparing sockfs <-> ext3, count 4 => 14 > [ 2.633095] strncmp: comparing bpf <-> ext3, count 4 => -3 > [ 2.633600] strncmp: comparing pipefs <-> ext3, count 4 => 11 > [ 2.634071] strncmp: comparing ramfs <-> ext3, count 4 => 13 > [ 2.634501] strncmp: comparing hugetlbfs <-> ext3, count 4 => 1 > [ 2.634955] strncmp: comparing rpc_pipefs <-> ext3, count 4 => 1 > [ 2.635407] strncmp: comparing devpts <-> ext3, count 4 => -1 > [ 2.638788] strncmp: comparing ext3 <-> ext3, count 4 => 0 > > > working - with normal strncmp: > [ 2.416438] strncmp: comparing /dev/vda <-> mtd, count 3 => -62 > [ 2.417312] strncmp: comparing /dev/vda <-> ubi, count 3 => -70 > [ 2.418296] strncmp: comparing /dev/vda <-> PARTUUID=, count 9 => -33 > [ 2.418921] strncmp: comparing /dev/vda <-> PARTLABEL=, count 10 => -33 > ------ below is the difference > [ 2.419450] strncmp: comparing /dev/vda <-> /dev/, count 5 => 0 > [ 2.420698] strncmp: comparing /dev/vda <-> /dev/, count 5 => 0 > ------ above is the difference > [ 2.424086] strncmp: comparing sysfs <-> ext3, count 4 => 14 > [ 2.424663] strncmp: comparing tmpfs <-> ext3, count 4 => 15 > [ 2.425111] strncmp: comparing bdev <-> ext3, count 4 => -3 > [ 2.425563] strncmp: comparing proc <-> ext3, count 4 => 11 > [ 2.426022] strncmp: comparing cgroup <-> ext3, count 4 => -2 > [ 2.426717] strncmp: comparing cgroup2 <-> ext3, count 4 => -2 > [ 2.427175] strncmp: comparing cpuset <-> ext3, count 4 => -2 > [ 2.427608] strncmp: comparing devtmpfs <-> ext3, count 4 => -1 > [ 2.428061] strncmp: comparing debugfs <-> ext3, count 4 => -1 > [ 2.428526] strncmp: comparing securityfs <-> ext3, count 4 => 14 > [ 2.428985] strncmp: comparing sockfs <-> ext3, count 4 => 14 > [ 2.429423] strncmp: comparing bpf <-> ext3, count 4 => -3 > [ 2.429863] strncmp: comparing pipefs <-> ext3, count 4 => 11 > [ 2.430433] strncmp: comparing ramfs <-> ext3, count 4 => 13 > [ 2.431202] strncmp: comparing hugetlbfs <-> ext3, count 4 => 3 > [ 2.431721] strncmp: comparing rpc_pipefs <-> ext3, count 4 => 13 > [ 2.432222] strncmp: comparing devpts <-> ext3, count 4 => -1 > [ 2.432685] strncmp: comparing ext3 <-> ext3, count 4 => 0 > > > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v1] RISC-V: take text_mutex during alternative patching 2023-02-22 19:06 ` Guenter Roeck @ 2023-02-22 20:33 ` Heiko Stübner 2023-02-22 22:10 ` Palmer Dabbelt 0 siblings, 1 reply; 20+ messages in thread From: Heiko Stübner @ 2023-02-22 20:33 UTC (permalink / raw) To: Palmer Dabbelt, Guenter Roeck Cc: ajones, Conor Dooley, Conor Dooley, samuel, linux-riscv, christoph.muellner Am Mittwoch, 22. Februar 2023, 20:06:56 CET schrieb Guenter Roeck: > On 2/22/23 09:43, Heiko Stübner wrote: > > Am Mittwoch, 22. Februar 2023, 18:03:55 CET schrieb Heiko Stübner: > >> Am Mittwoch, 22. Februar 2023, 17:47:10 CET schrieb Palmer Dabbelt: > >>> On Wed, 22 Feb 2023 07:39:11 PST (-0800), heiko@sntech.de wrote: > >>>> Am Mittwoch, 22. Februar 2023, 16:31:25 CET schrieb Andrew Jones: > >>>>> On Wed, Feb 22, 2023 at 03:27:43PM +0100, Andrew Jones wrote: > >>>>>> On Thu, Feb 16, 2023 at 07:33:55AM -0800, Guenter Roeck wrote: > >>>>>>> On 2/15/23 14:00, Heiko Stübner wrote: > >>>>>>> [ ... ] > >>>>>>>> > >>>>>>>> So now I've also tested Palmer's for-next at > >>>>>>>> commit ec6311919ea6 ("Merge patch series "riscv: Optimize function trace"") > >>>>>>>> > >>>>>>>> again with the same variants > >>>>>>>> - qemu-riscv32 without zbb > >>>>>>>> - qemu-riscv32 with zbb > >>>>>>>> - qemu-riscv64 without zbb > >>>>>>>> - qemu-riscv64 with zbb > >>>>>>>> > >>>>>>>> And all of them booted fine into a nfs-root (debian for riscv64 and a > >>>>>>>> buildroot for riscv32). > >>>>>>>> > >>>>>>>> I even forced a bug into the zbb code to make sure the patching worked > >>>>>>>> correctly (where the kernel failed as expected). > >>>>>>>> > >>>>>>>> Qemu-version for me was 7.2.50 (v7.2.0-744-g5a3633929a-dirty) > >>>>>>>> > >>>>>>>> I did try the one from Debian-stable (qemu-5.2) but that was too old and > >>>>>>>> didn't support Zbb yet. > >>>>>>>> > >>>>>>>> One thing of note, the "active" 32bit config I had, somehow didn't produce > >>>>>>>> working images and I needed to start a new build using the rv32_defconfig. > >>>>>>>> > >>>>>>>> So right now, I'm not sure what more to test though. > >>>>>>>> > >>>>>>> > >>>>>>> Another example: > >>>>>>> > >>>>>>> - build defconfig > >>>>>>> - run > >>>>>>> qemu-system-riscv64 -M virt -m 512M -no-reboot -kernel arch/riscv/boot/Image \ > >>>>>>> -snapshot -device virtio-blk-device,drive=d0 -drive file=rootfs.ext2,if=none,id=d0,format=raw \ > >>>>>>> -append "root=/dev/vda console=ttyS0,115200 earlycon=uart8250,mmio,0x10000000,115200" \ > >>>>>>> -nographic -monitor none > >>>>>>> > >>>>>>> With CONFIG_RISCV_ISA_ZBB=y, that results in > >>>>>>> > >>>>>>> [ 0.818263] /dev/root: Can't open blockdev > >>>>>>> [ 0.818856] VFS: Cannot open root device "/dev/vda" or unknown-block(0,0): error -6 > >>>>>>> [ 0.819177] Please append a correct "root=" boot option; here are the available partitions: > >>>>>>> [ 0.819808] fe00 16384 vda > >>>>>>> [ 0.819944] driver: virtio_blk > >>>>>>> [ 0.820534] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) > >>>>>>> [ 0.821101] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.2.0-rc8-next-20230216-00002-g80332825e240 #4 > >>>>>>> [ 0.821672] Hardware name: riscv-virtio,qemu (DT) > >>>>>>> [ 0.822050] Call Trace: > >>>>>>> [ 0.822427] [<ffffffff800053e4>] dump_backtrace+0x1c/0x24 > >>>>>>> [ 0.822834] [<ffffffff807f90e4>] show_stack+0x2c/0x38 > >>>>>>> [ 0.823085] [<ffffffff80803aea>] dump_stack_lvl+0x3c/0x54 > >>>>>>> [ 0.823351] [<ffffffff80803b16>] dump_stack+0x14/0x1c > >>>>>>> [ 0.823601] [<ffffffff807f944c>] panic+0x102/0x29e > >>>>>>> [ 0.823834] [<ffffffff80a015e2>] mount_block_root+0x18c/0x23e > >>>>>>> [ 0.824148] [<ffffffff80a0187c>] mount_root+0x1e8/0x218 > >>>>>>> [ 0.824398] [<ffffffff80a019ee>] prepare_namespace+0x142/0x184 > >>>>>>> [ 0.824655] [<ffffffff80a01182>] kernel_init_freeable+0x236/0x25a > >>>>>>> [ 0.824934] [<ffffffff80804602>] kernel_init+0x1e/0x10a > >>>>>>> [ 0.825201] [<ffffffff80003560>] ret_from_exception+0x0/0x16 > >>>>>>> [ 0.826180] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]--- > >>>>>>> > >>>>>>> This works fine if CONFIG_RISCV_ISA_ZBB is not enabled. > >>>>>>> > >>>>>>> Tested with gcc 11.3, binutils 2.39, qemu v7.2.0 and qemu built from mainline. > >>>>>>> > >>>>>> > >>>>>> Just to +1 this, I get the same result (unable to mount root fs) with > >>>>>> > >>>>>> $QEMU -cpu rv64,zbb=on \ > >>>>>> -nographic \ > >>>>>> -machine virt \ > >>>>>> -kernel $KERNEL \ > >>>>>> -append 'root=/dev/vda console=ttyS0' \ > >>>>>> -drive file=disk.ext4,format=raw,id=hd0 \ > >>>>>> -device virtio-blk-pci,drive=hd0 > >>>>>> > >>>>>> kernel: latest riscv-linux/for-next (8658db0a4a0f), defconfig > >>>>>> gcc: riscv-gnu-toolchain (12.1.0) > >>>>>> binutils: riscv-gnu-toolchain (2.39) > >>>>>> qemu: latest master (79b677d658d3) > >>>>>> > >>>>>> Flipping the QEMU cpu zbb property off allows boot to succeed, i.e. it's > >>>>>> not necessary to compile out the CONFIG_RISCV_ISA_ZBB code from the > >>>>>> kernel, it's just necessary to avoid using it. > >>>>>> > >>>>> > >>>>> Looks like something in the strncmp implementation. Only commenting it > >>>>> out allows boot to succeed. > >>>> > >>>> and interestingly it seems to be something very specific. I.e. my setup is > >>>> nfsroot-based (qemu is "just" another board in my boardfarm) and booting > >>>> into an nfs-root works quite nicely. > >>>> > >>>> I guess I need to look into how to get an actual disk-image in there. > >>> > >>> It looks like Drew isn't using an initrd (and with NFS, presumably you > >>> are)? That's probably a big difference as well. > >> > >> There is no initrd involved in my qemu setup ;-) . > >> Just a kernel built from current for-next + defconfig and a nfs-server > >> holding a full Debian-riscv64 system. > >> > >> > >> The magic qemu incantation is also pretty standard: > >> > >> /usr/local/bin/qemu-system-riscv64 -M virt -smp 2 -m 1G -display none \ > >> -cpu rv64,zbb=true,zbc=true,svpbmt=true,Zicbom=true,Zawrs=true,sscofpmf=true,v=true \ > >> -serial telnet:localhost:5500,server,nowait -kernel /home/devel/nfs/kernel/riscv64/Image \ > >> -append earlycon=sbi root=/dev/nfs nfsroot=10.0.2.2:/home/devel/nfs/rootfs-riscv64virt ip=dhcp rw \ > >> -netdev user,id=n1 -device virtio-net-pci,netdev=n1 -name boardfarm-0,process=boardfarm-vm-0 -daemonize > >> > >> > >> And I also checked that my kernel really lands in the Zbb-code by simply > >> adding a "ret" [0] and making sure it breaks vs. runs without it > >> > >> > >> Next I'll try to move my rootfs into a real image-file and switch over to > >> the commandline Drew calls, to see if it'll reproduce then. > > > > With the rootfs in an image I could reproduce the issue now. > > > > I hacked in a very crude change to find the invocation that acts differently > > and voila it's a strncmp of the "/dev/vda" against "/dev/" [0]. > > > > It's really strange that all the other invocations produce correct results. > > > > Not really; the failures are the only comparisons which are expected to > return 0 and are not a complete string match. > > I'd suspect that strncmp(s1, s2, strlen(s2)) will always return > a bad result if s1 starts with s2 but is not identical to s2. The issue seems to come into play when s2 is shorter than the stepsize for the bitops-accelerated part (reg-size being 8) here. I.e. strncmp("/dev/vda", "/dev/", 5): 1 strncmp("/dev/vda", "/dev", 4): 1 strncmp("/dev/vda", "/de", 3): 1 ... but strncmp("/dev/vda12", "/dev/vda", 8): 0 strncmp("/dev/vda12", "/dev/vda1", 9): 0 For size-9 this succeeds because the first step is "/dev/vda" and the 0byte in "12" is detected and jumps to processing the rest individually. Duplicating the 0-byte check for s2 [1] - i.e. jumping to the byte-wise path when a 0-byte is detected in the second string - solves the issue. Not sure if there is a more performant solution for this, because we do have the length available. I'll think some more about that part. Heiko [1] @@ -83,6 +83,8 @@ strncmp_zbb: REG_L t1, 0(a1) orc.b t3, t0 bne t3, t5, 2f + orc.b t3, t1 + bne t3, t5, 2f addi a0, a0, SZREG addi a1, a1, SZREG beq t0, t1, 1b > > [0] > > non-working - with zbb-strncmp: > > [ 2.619129] strncmp: comparing /dev/vda <-> mtd, count 3 => -1 > > [ 2.620451] strncmp: comparing /dev/vda <-> ubi, count 3 => -1 > > [ 2.621163] strncmp: comparing /dev/vda <-> PARTUUID=, count 9 => -1 > > [ 2.621703] strncmp: comparing /dev/vda <-> PARTLABEL=, count 10 => -1 > > ------ below is the difference > > [ 2.622255] strncmp: comparing /dev/vda <-> /dev/, count 5 => 1 > > [ 2.623446] strncmp: comparing /dev/vda <-> /dev/, count 5 => 1 > > ------ above is the difference > > [ 2.627064] strncmp: comparing sysfs <-> ext3, count 4 => 14 > > [ 2.627646] strncmp: comparing tmpfs <-> ext3, count 4 => 15 > > [ 2.628476] strncmp: comparing bdev <-> ext3, count 4 => -3 > > [ 2.628990] strncmp: comparing proc <-> ext3, count 4 => 11 > > [ 2.629422] strncmp: comparing cgroup <-> ext3, count 4 => -2 > > [ 2.629856] strncmp: comparing cgroup2 <-> ext3, count 4 => -2 > > [ 2.630345] strncmp: comparing cpuset <-> ext3, count 4 => -2 > > [ 2.630785] strncmp: comparing devtmpfs <-> ext3, count 4 => -1 > > [ 2.631267] strncmp: comparing debugfs <-> ext3, count 4 => -1 > > [ 2.631696] strncmp: comparing securityfs <-> ext3, count 4 => 1 > > [ 2.632596] strncmp: comparing sockfs <-> ext3, count 4 => 14 > > [ 2.633095] strncmp: comparing bpf <-> ext3, count 4 => -3 > > [ 2.633600] strncmp: comparing pipefs <-> ext3, count 4 => 11 > > [ 2.634071] strncmp: comparing ramfs <-> ext3, count 4 => 13 > > [ 2.634501] strncmp: comparing hugetlbfs <-> ext3, count 4 => 1 > > [ 2.634955] strncmp: comparing rpc_pipefs <-> ext3, count 4 => 1 > > [ 2.635407] strncmp: comparing devpts <-> ext3, count 4 => -1 > > [ 2.638788] strncmp: comparing ext3 <-> ext3, count 4 => 0 > > > > > > working - with normal strncmp: > > [ 2.416438] strncmp: comparing /dev/vda <-> mtd, count 3 => -62 > > [ 2.417312] strncmp: comparing /dev/vda <-> ubi, count 3 => -70 > > [ 2.418296] strncmp: comparing /dev/vda <-> PARTUUID=, count 9 => -33 > > [ 2.418921] strncmp: comparing /dev/vda <-> PARTLABEL=, count 10 => -33 > > ------ below is the difference > > [ 2.419450] strncmp: comparing /dev/vda <-> /dev/, count 5 => 0 > > [ 2.420698] strncmp: comparing /dev/vda <-> /dev/, count 5 => 0 > > ------ above is the difference > > [ 2.424086] strncmp: comparing sysfs <-> ext3, count 4 => 14 > > [ 2.424663] strncmp: comparing tmpfs <-> ext3, count 4 => 15 > > [ 2.425111] strncmp: comparing bdev <-> ext3, count 4 => -3 > > [ 2.425563] strncmp: comparing proc <-> ext3, count 4 => 11 > > [ 2.426022] strncmp: comparing cgroup <-> ext3, count 4 => -2 > > [ 2.426717] strncmp: comparing cgroup2 <-> ext3, count 4 => -2 > > [ 2.427175] strncmp: comparing cpuset <-> ext3, count 4 => -2 > > [ 2.427608] strncmp: comparing devtmpfs <-> ext3, count 4 => -1 > > [ 2.428061] strncmp: comparing debugfs <-> ext3, count 4 => -1 > > [ 2.428526] strncmp: comparing securityfs <-> ext3, count 4 => 14 > > [ 2.428985] strncmp: comparing sockfs <-> ext3, count 4 => 14 > > [ 2.429423] strncmp: comparing bpf <-> ext3, count 4 => -3 > > [ 2.429863] strncmp: comparing pipefs <-> ext3, count 4 => 11 > > [ 2.430433] strncmp: comparing ramfs <-> ext3, count 4 => 13 > > [ 2.431202] strncmp: comparing hugetlbfs <-> ext3, count 4 => 3 > > [ 2.431721] strncmp: comparing rpc_pipefs <-> ext3, count 4 => 13 > > [ 2.432222] strncmp: comparing devpts <-> ext3, count 4 => -1 > > [ 2.432685] strncmp: comparing ext3 <-> ext3, count 4 => 0 > > > > > > > > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v1] RISC-V: take text_mutex during alternative patching 2023-02-22 20:33 ` Heiko Stübner @ 2023-02-22 22:10 ` Palmer Dabbelt 0 siblings, 0 replies; 20+ messages in thread From: Palmer Dabbelt @ 2023-02-22 22:10 UTC (permalink / raw) To: heiko Cc: linux, ajones, Conor Dooley, Conor Dooley, samuel, linux-riscv, christoph.muellner On Wed, 22 Feb 2023 12:33:47 PST (-0800), heiko@sntech.de wrote: > Am Mittwoch, 22. Februar 2023, 20:06:56 CET schrieb Guenter Roeck: >> On 2/22/23 09:43, Heiko Stübner wrote: >> > Am Mittwoch, 22. Februar 2023, 18:03:55 CET schrieb Heiko Stübner: >> >> Am Mittwoch, 22. Februar 2023, 17:47:10 CET schrieb Palmer Dabbelt: >> >>> On Wed, 22 Feb 2023 07:39:11 PST (-0800), heiko@sntech.de wrote: >> >>>> Am Mittwoch, 22. Februar 2023, 16:31:25 CET schrieb Andrew Jones: >> >>>>> On Wed, Feb 22, 2023 at 03:27:43PM +0100, Andrew Jones wrote: >> >>>>>> On Thu, Feb 16, 2023 at 07:33:55AM -0800, Guenter Roeck wrote: >> >>>>>>> On 2/15/23 14:00, Heiko Stübner wrote: >> >>>>>>> [ ... ] >> >>>>>>>> >> >>>>>>>> So now I've also tested Palmer's for-next at >> >>>>>>>> commit ec6311919ea6 ("Merge patch series "riscv: Optimize function trace"") >> >>>>>>>> >> >>>>>>>> again with the same variants >> >>>>>>>> - qemu-riscv32 without zbb >> >>>>>>>> - qemu-riscv32 with zbb >> >>>>>>>> - qemu-riscv64 without zbb >> >>>>>>>> - qemu-riscv64 with zbb >> >>>>>>>> >> >>>>>>>> And all of them booted fine into a nfs-root (debian for riscv64 and a >> >>>>>>>> buildroot for riscv32). >> >>>>>>>> >> >>>>>>>> I even forced a bug into the zbb code to make sure the patching worked >> >>>>>>>> correctly (where the kernel failed as expected). >> >>>>>>>> >> >>>>>>>> Qemu-version for me was 7.2.50 (v7.2.0-744-g5a3633929a-dirty) >> >>>>>>>> >> >>>>>>>> I did try the one from Debian-stable (qemu-5.2) but that was too old and >> >>>>>>>> didn't support Zbb yet. >> >>>>>>>> >> >>>>>>>> One thing of note, the "active" 32bit config I had, somehow didn't produce >> >>>>>>>> working images and I needed to start a new build using the rv32_defconfig. >> >>>>>>>> >> >>>>>>>> So right now, I'm not sure what more to test though. >> >>>>>>>> >> >>>>>>> >> >>>>>>> Another example: >> >>>>>>> >> >>>>>>> - build defconfig >> >>>>>>> - run >> >>>>>>> qemu-system-riscv64 -M virt -m 512M -no-reboot -kernel arch/riscv/boot/Image \ >> >>>>>>> -snapshot -device virtio-blk-device,drive=d0 -drive file=rootfs.ext2,if=none,id=d0,format=raw \ >> >>>>>>> -append "root=/dev/vda console=ttyS0,115200 earlycon=uart8250,mmio,0x10000000,115200" \ >> >>>>>>> -nographic -monitor none >> >>>>>>> >> >>>>>>> With CONFIG_RISCV_ISA_ZBB=y, that results in >> >>>>>>> >> >>>>>>> [ 0.818263] /dev/root: Can't open blockdev >> >>>>>>> [ 0.818856] VFS: Cannot open root device "/dev/vda" or unknown-block(0,0): error -6 >> >>>>>>> [ 0.819177] Please append a correct "root=" boot option; here are the available partitions: >> >>>>>>> [ 0.819808] fe00 16384 vda >> >>>>>>> [ 0.819944] driver: virtio_blk >> >>>>>>> [ 0.820534] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) >> >>>>>>> [ 0.821101] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.2.0-rc8-next-20230216-00002-g80332825e240 #4 >> >>>>>>> [ 0.821672] Hardware name: riscv-virtio,qemu (DT) >> >>>>>>> [ 0.822050] Call Trace: >> >>>>>>> [ 0.822427] [<ffffffff800053e4>] dump_backtrace+0x1c/0x24 >> >>>>>>> [ 0.822834] [<ffffffff807f90e4>] show_stack+0x2c/0x38 >> >>>>>>> [ 0.823085] [<ffffffff80803aea>] dump_stack_lvl+0x3c/0x54 >> >>>>>>> [ 0.823351] [<ffffffff80803b16>] dump_stack+0x14/0x1c >> >>>>>>> [ 0.823601] [<ffffffff807f944c>] panic+0x102/0x29e >> >>>>>>> [ 0.823834] [<ffffffff80a015e2>] mount_block_root+0x18c/0x23e >> >>>>>>> [ 0.824148] [<ffffffff80a0187c>] mount_root+0x1e8/0x218 >> >>>>>>> [ 0.824398] [<ffffffff80a019ee>] prepare_namespace+0x142/0x184 >> >>>>>>> [ 0.824655] [<ffffffff80a01182>] kernel_init_freeable+0x236/0x25a >> >>>>>>> [ 0.824934] [<ffffffff80804602>] kernel_init+0x1e/0x10a >> >>>>>>> [ 0.825201] [<ffffffff80003560>] ret_from_exception+0x0/0x16 >> >>>>>>> [ 0.826180] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]--- >> >>>>>>> >> >>>>>>> This works fine if CONFIG_RISCV_ISA_ZBB is not enabled. >> >>>>>>> >> >>>>>>> Tested with gcc 11.3, binutils 2.39, qemu v7.2.0 and qemu built from mainline. >> >>>>>>> >> >>>>>> >> >>>>>> Just to +1 this, I get the same result (unable to mount root fs) with >> >>>>>> >> >>>>>> $QEMU -cpu rv64,zbb=on \ >> >>>>>> -nographic \ >> >>>>>> -machine virt \ >> >>>>>> -kernel $KERNEL \ >> >>>>>> -append 'root=/dev/vda console=ttyS0' \ >> >>>>>> -drive file=disk.ext4,format=raw,id=hd0 \ >> >>>>>> -device virtio-blk-pci,drive=hd0 >> >>>>>> >> >>>>>> kernel: latest riscv-linux/for-next (8658db0a4a0f), defconfig >> >>>>>> gcc: riscv-gnu-toolchain (12.1.0) >> >>>>>> binutils: riscv-gnu-toolchain (2.39) >> >>>>>> qemu: latest master (79b677d658d3) >> >>>>>> >> >>>>>> Flipping the QEMU cpu zbb property off allows boot to succeed, i.e. it's >> >>>>>> not necessary to compile out the CONFIG_RISCV_ISA_ZBB code from the >> >>>>>> kernel, it's just necessary to avoid using it. >> >>>>>> >> >>>>> >> >>>>> Looks like something in the strncmp implementation. Only commenting it >> >>>>> out allows boot to succeed. >> >>>> >> >>>> and interestingly it seems to be something very specific. I.e. my setup is >> >>>> nfsroot-based (qemu is "just" another board in my boardfarm) and booting >> >>>> into an nfs-root works quite nicely. >> >>>> >> >>>> I guess I need to look into how to get an actual disk-image in there. >> >>> >> >>> It looks like Drew isn't using an initrd (and with NFS, presumably you >> >>> are)? That's probably a big difference as well. >> >> >> >> There is no initrd involved in my qemu setup ;-) . >> >> Just a kernel built from current for-next + defconfig and a nfs-server >> >> holding a full Debian-riscv64 system. >> >> >> >> >> >> The magic qemu incantation is also pretty standard: >> >> >> >> /usr/local/bin/qemu-system-riscv64 -M virt -smp 2 -m 1G -display none \ >> >> -cpu rv64,zbb=true,zbc=true,svpbmt=true,Zicbom=true,Zawrs=true,sscofpmf=true,v=true \ >> >> -serial telnet:localhost:5500,server,nowait -kernel /home/devel/nfs/kernel/riscv64/Image \ >> >> -append earlycon=sbi root=/dev/nfs nfsroot=10.0.2.2:/home/devel/nfs/rootfs-riscv64virt ip=dhcp rw \ >> >> -netdev user,id=n1 -device virtio-net-pci,netdev=n1 -name boardfarm-0,process=boardfarm-vm-0 -daemonize >> >> >> >> >> >> And I also checked that my kernel really lands in the Zbb-code by simply >> >> adding a "ret" [0] and making sure it breaks vs. runs without it >> >> >> >> >> >> Next I'll try to move my rootfs into a real image-file and switch over to >> >> the commandline Drew calls, to see if it'll reproduce then. >> > >> > With the rootfs in an image I could reproduce the issue now. >> > >> > I hacked in a very crude change to find the invocation that acts differently >> > and voila it's a strncmp of the "/dev/vda" against "/dev/" [0]. >> > >> > It's really strange that all the other invocations produce correct results. >> > >> >> Not really; the failures are the only comparisons which are expected to >> return 0 and are not a complete string match. >> >> I'd suspect that strncmp(s1, s2, strlen(s2)) will always return >> a bad result if s1 starts with s2 but is not identical to s2. > > The issue seems to come into play when s2 is shorter than the stepsize > for the bitops-accelerated part (reg-size being 8) here. > > I.e. > > strncmp("/dev/vda", "/dev/", 5): 1 I'd tried pulling out your failures from the previous message into the selftests, turns out this one happens to fail for me. From looking at the code I'd figured it was this fetch-past-nul issue so I'd added some alignment skewing, but it looks like it happens to trigger for me without any. I sent a patch to add the test here <https://lore.kernel.org/r/20230222220435.10688-1-palmer@rivosinc.com/> > strncmp("/dev/vda", "/dev", 4): 1 > strncmp("/dev/vda", "/de", 3): 1 > ... > but > strncmp("/dev/vda12", "/dev/vda", 8): 0 > strncmp("/dev/vda12", "/dev/vda1", 9): 0 > > For size-9 this succeeds because the first step is "/dev/vda" and the > 0byte in "12" is detected and jumps to processing the rest individually. > > Duplicating the 0-byte check for s2 [1] - i.e. jumping to the byte-wise > path when a 0-byte is detected in the second string - solves the issue. > > Not sure if there is a more performant solution for this, because we do > have the length available. I'll think some more about that part. The only way I could come up with was to check the length and fall back to the byte routines. That may or may not be faster depending on loop counts and such, I doubt it matters until we get to proper uarch-optimized routines. > > > Heiko > > > [1] > @@ -83,6 +83,8 @@ strncmp_zbb: > REG_L t1, 0(a1) > orc.b t3, t0 > bne t3, t5, 2f > + orc.b t3, t1 > + bne t3, t5, 2f > addi a0, a0, SZREG > addi a1, a1, SZREG > beq t0, t1, 1b > > > >> > [0] >> > non-working - with zbb-strncmp: >> > [ 2.619129] strncmp: comparing /dev/vda <-> mtd, count 3 => -1 >> > [ 2.620451] strncmp: comparing /dev/vda <-> ubi, count 3 => -1 >> > [ 2.621163] strncmp: comparing /dev/vda <-> PARTUUID=, count 9 => -1 >> > [ 2.621703] strncmp: comparing /dev/vda <-> PARTLABEL=, count 10 => -1 >> > ------ below is the difference >> > [ 2.622255] strncmp: comparing /dev/vda <-> /dev/, count 5 => 1 >> > [ 2.623446] strncmp: comparing /dev/vda <-> /dev/, count 5 => 1 >> > ------ above is the difference >> > [ 2.627064] strncmp: comparing sysfs <-> ext3, count 4 => 14 >> > [ 2.627646] strncmp: comparing tmpfs <-> ext3, count 4 => 15 >> > [ 2.628476] strncmp: comparing bdev <-> ext3, count 4 => -3 >> > [ 2.628990] strncmp: comparing proc <-> ext3, count 4 => 11 >> > [ 2.629422] strncmp: comparing cgroup <-> ext3, count 4 => -2 >> > [ 2.629856] strncmp: comparing cgroup2 <-> ext3, count 4 => -2 >> > [ 2.630345] strncmp: comparing cpuset <-> ext3, count 4 => -2 >> > [ 2.630785] strncmp: comparing devtmpfs <-> ext3, count 4 => -1 >> > [ 2.631267] strncmp: comparing debugfs <-> ext3, count 4 => -1 >> > [ 2.631696] strncmp: comparing securityfs <-> ext3, count 4 => 1 >> > [ 2.632596] strncmp: comparing sockfs <-> ext3, count 4 => 14 >> > [ 2.633095] strncmp: comparing bpf <-> ext3, count 4 => -3 >> > [ 2.633600] strncmp: comparing pipefs <-> ext3, count 4 => 11 >> > [ 2.634071] strncmp: comparing ramfs <-> ext3, count 4 => 13 >> > [ 2.634501] strncmp: comparing hugetlbfs <-> ext3, count 4 => 1 >> > [ 2.634955] strncmp: comparing rpc_pipefs <-> ext3, count 4 => 1 >> > [ 2.635407] strncmp: comparing devpts <-> ext3, count 4 => -1 >> > [ 2.638788] strncmp: comparing ext3 <-> ext3, count 4 => 0 >> > >> > >> > working - with normal strncmp: >> > [ 2.416438] strncmp: comparing /dev/vda <-> mtd, count 3 => -62 >> > [ 2.417312] strncmp: comparing /dev/vda <-> ubi, count 3 => -70 >> > [ 2.418296] strncmp: comparing /dev/vda <-> PARTUUID=, count 9 => -33 >> > [ 2.418921] strncmp: comparing /dev/vda <-> PARTLABEL=, count 10 => -33 >> > ------ below is the difference >> > [ 2.419450] strncmp: comparing /dev/vda <-> /dev/, count 5 => 0 >> > [ 2.420698] strncmp: comparing /dev/vda <-> /dev/, count 5 => 0 >> > ------ above is the difference >> > [ 2.424086] strncmp: comparing sysfs <-> ext3, count 4 => 14 >> > [ 2.424663] strncmp: comparing tmpfs <-> ext3, count 4 => 15 >> > [ 2.425111] strncmp: comparing bdev <-> ext3, count 4 => -3 >> > [ 2.425563] strncmp: comparing proc <-> ext3, count 4 => 11 >> > [ 2.426022] strncmp: comparing cgroup <-> ext3, count 4 => -2 >> > [ 2.426717] strncmp: comparing cgroup2 <-> ext3, count 4 => -2 >> > [ 2.427175] strncmp: comparing cpuset <-> ext3, count 4 => -2 >> > [ 2.427608] strncmp: comparing devtmpfs <-> ext3, count 4 => -1 >> > [ 2.428061] strncmp: comparing debugfs <-> ext3, count 4 => -1 >> > [ 2.428526] strncmp: comparing securityfs <-> ext3, count 4 => 14 >> > [ 2.428985] strncmp: comparing sockfs <-> ext3, count 4 => 14 >> > [ 2.429423] strncmp: comparing bpf <-> ext3, count 4 => -3 >> > [ 2.429863] strncmp: comparing pipefs <-> ext3, count 4 => 11 >> > [ 2.430433] strncmp: comparing ramfs <-> ext3, count 4 => 13 >> > [ 2.431202] strncmp: comparing hugetlbfs <-> ext3, count 4 => 3 >> > [ 2.431721] strncmp: comparing rpc_pipefs <-> ext3, count 4 => 13 >> > [ 2.432222] strncmp: comparing devpts <-> ext3, count 4 => -1 >> > [ 2.432685] strncmp: comparing ext3 <-> ext3, count 4 => 0 >> > >> > >> > >> >> _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* RISC-V Zbb QEMU Boot Failures (was Re: [PATCH v1] RISC-V: take text_mutex during alternative patching) 2023-02-22 14:27 ` Andrew Jones 2023-02-22 15:31 ` Andrew Jones @ 2023-02-22 16:17 ` Palmer Dabbelt 1 sibling, 0 replies; 20+ messages in thread From: Palmer Dabbelt @ 2023-02-22 16:17 UTC (permalink / raw) To: ajones, Paul Walmsley Cc: linux, heiko, Conor Dooley, Conor Dooley, samuel, linux-riscv On Wed, 22 Feb 2023 06:27:43 PST (-0800), ajones@ventanamicro.com wrote: > On Thu, Feb 16, 2023 at 07:33:55AM -0800, Guenter Roeck wrote: >> On 2/15/23 14:00, Heiko Stübner wrote: >> [ ... ] >> > >> > So now I've also tested Palmer's for-next at >> > commit ec6311919ea6 ("Merge patch series "riscv: Optimize function trace"") >> > >> > again with the same variants >> > - qemu-riscv32 without zbb >> > - qemu-riscv32 with zbb >> > - qemu-riscv64 without zbb >> > - qemu-riscv64 with zbb >> > >> > And all of them booted fine into a nfs-root (debian for riscv64 and a >> > buildroot for riscv32). >> > >> > I even forced a bug into the zbb code to make sure the patching worked >> > correctly (where the kernel failed as expected). >> > >> > Qemu-version for me was 7.2.50 (v7.2.0-744-g5a3633929a-dirty) >> > >> > I did try the one from Debian-stable (qemu-5.2) but that was too old and >> > didn't support Zbb yet. >> > >> > One thing of note, the "active" 32bit config I had, somehow didn't produce >> > working images and I needed to start a new build using the rv32_defconfig. >> > >> > So right now, I'm not sure what more to test though. >> > >> >> Another example: >> >> - build defconfig >> - run >> qemu-system-riscv64 -M virt -m 512M -no-reboot -kernel arch/riscv/boot/Image \ >> -snapshot -device virtio-blk-device,drive=d0 -drive file=rootfs.ext2,if=none,id=d0,format=raw \ >> -append "root=/dev/vda console=ttyS0,115200 earlycon=uart8250,mmio,0x10000000,115200" \ >> -nographic -monitor none >> >> With CONFIG_RISCV_ISA_ZBB=y, that results in >> >> [ 0.818263] /dev/root: Can't open blockdev >> [ 0.818856] VFS: Cannot open root device "/dev/vda" or unknown-block(0,0): error -6 >> [ 0.819177] Please append a correct "root=" boot option; here are the available partitions: >> [ 0.819808] fe00 16384 vda >> [ 0.819944] driver: virtio_blk >> [ 0.820534] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) >> [ 0.821101] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.2.0-rc8-next-20230216-00002-g80332825e240 #4 >> [ 0.821672] Hardware name: riscv-virtio,qemu (DT) >> [ 0.822050] Call Trace: >> [ 0.822427] [<ffffffff800053e4>] dump_backtrace+0x1c/0x24 >> [ 0.822834] [<ffffffff807f90e4>] show_stack+0x2c/0x38 >> [ 0.823085] [<ffffffff80803aea>] dump_stack_lvl+0x3c/0x54 >> [ 0.823351] [<ffffffff80803b16>] dump_stack+0x14/0x1c >> [ 0.823601] [<ffffffff807f944c>] panic+0x102/0x29e >> [ 0.823834] [<ffffffff80a015e2>] mount_block_root+0x18c/0x23e >> [ 0.824148] [<ffffffff80a0187c>] mount_root+0x1e8/0x218 >> [ 0.824398] [<ffffffff80a019ee>] prepare_namespace+0x142/0x184 >> [ 0.824655] [<ffffffff80a01182>] kernel_init_freeable+0x236/0x25a >> [ 0.824934] [<ffffffff80804602>] kernel_init+0x1e/0x10a >> [ 0.825201] [<ffffffff80003560>] ret_from_exception+0x0/0x16 >> [ 0.826180] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]--- >> >> This works fine if CONFIG_RISCV_ISA_ZBB is not enabled. >> >> Tested with gcc 11.3, binutils 2.39, qemu v7.2.0 and qemu built from mainline. >> > > Just to +1 this, I get the same result (unable to mount root fs) with > > $QEMU -cpu rv64,zbb=on \ > -nographic \ > -machine virt \ > -kernel $KERNEL \ > -append 'root=/dev/vda console=ttyS0' \ > -drive file=disk.ext4,format=raw,id=hd0 \ > -device virtio-blk-pci,drive=hd0 > > kernel: latest riscv-linux/for-next (8658db0a4a0f), defconfig > gcc: riscv-gnu-toolchain (12.1.0) > binutils: riscv-gnu-toolchain (2.39) > qemu: latest master (79b677d658d3) > > Flipping the QEMU cpu zbb property off allows boot to succeed, i.e. it's > not necessary to compile out the CONFIG_RISCV_ISA_ZBB code from the > kernel, it's just necessary to avoid using it. Thanks for finding this. I'm changing the subject line and adding Paul, as it came up during the patchwork call. I added zbb=on for rv32 and rv64 to my tests and they pass, but I'm not mounting a rootfs... > > Thanks, > drew _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v1] RISC-V: take text_mutex during alternative patching 2023-02-12 19:47 [PATCH v1] RISC-V: take text_mutex during alternative patching Conor Dooley 2023-02-12 19:58 ` Samuel Holland 2023-02-12 23:08 ` Guenter Roeck @ 2023-02-22 15:00 ` patchwork-bot+linux-riscv 2 siblings, 0 replies; 20+ messages in thread From: patchwork-bot+linux-riscv @ 2023-02-22 15:00 UTC (permalink / raw) To: Conor Dooley; +Cc: linux-riscv, palmer, conor.dooley, samuel, linux, ajones Hello: This patch was applied to riscv/linux.git (for-next) by Palmer Dabbelt <palmer@rivosinc.com>: On Sun, 12 Feb 2023 19:47:36 +0000 you wrote: > From: Conor Dooley <conor.dooley@microchip.com> > > Guenter reported a splat during boot, that Samuel pointed out was the > lockdep assertion failing in patch_insn_write(): > > WARNING: CPU: 0 PID: 0 at arch/riscv/kernel/patch.c:63 patch_insn_write+0x222/0x2f6 > epc : patch_insn_write+0x222/0x2f6 > ra : patch_insn_write+0x21e/0x2f6 > epc : ffffffff800068c6 ra : ffffffff800068c2 sp : ffffffff81803df0 > gp : ffffffff81a1ab78 tp : ffffffff81814f80 t0 : ffffffffffffe000 > t1 : 0000000000000001 t2 : 4c45203a76637369 s0 : ffffffff81803e40 > s1 : 0000000000000004 a0 : 0000000000000000 a1 : ffffffffffffffff > a2 : 0000000000000004 a3 : 0000000000000000 a4 : 0000000000000001 > a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000052464e43 > s2 : ffffffff80b4889c s3 : 000000000000082c s4 : ffffffff80b48828 > s5 : 0000000000000828 s6 : ffffffff8131a0a0 s7 : 0000000000000fff > s8 : 0000000008000200 s9 : ffffffff8131a520 s10: 0000000000000018 > s11: 000000000000000b t3 : 0000000000000001 t4 : 000000000000000d > t5 : ffffffffd8180000 t6 : ffffffff81803bc8 > status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 > [<ffffffff800068c6>] patch_insn_write+0x222/0x2f6 > [<ffffffff80006a36>] patch_text_nosync+0xc/0x2a > [<ffffffff80003b86>] riscv_cpufeature_patch_func+0x52/0x98 > [<ffffffff80003348>] _apply_alternatives+0x46/0x86 > [<ffffffff80c02d36>] apply_boot_alternatives+0x3c/0xfa > [<ffffffff80c03ad8>] setup_arch+0x584/0x5b8 > [<ffffffff80c0075a>] start_kernel+0xa2/0x8f8 > > [...] Here is the summary with links: - [v1] RISC-V: take text_mutex during alternative patching https://git.kernel.org/riscv/c/9493e6f3ce02 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2023-02-22 22:10 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-02-12 19:47 [PATCH v1] RISC-V: take text_mutex during alternative patching Conor Dooley 2023-02-12 19:58 ` Samuel Holland 2023-02-12 23:08 ` Guenter Roeck 2023-02-13 22:40 ` Conor Dooley 2023-02-15 14:43 ` Heiko Stübner 2023-02-15 22:00 ` Heiko Stübner 2023-02-16 0:22 ` Guenter Roeck 2023-02-16 7:07 ` Guenter Roeck 2023-02-16 15:33 ` Guenter Roeck 2023-02-22 14:27 ` Andrew Jones 2023-02-22 15:31 ` Andrew Jones 2023-02-22 15:39 ` Heiko Stübner 2023-02-22 16:47 ` Palmer Dabbelt 2023-02-22 17:03 ` Heiko Stübner 2023-02-22 17:43 ` Heiko Stübner 2023-02-22 19:06 ` Guenter Roeck 2023-02-22 20:33 ` Heiko Stübner 2023-02-22 22:10 ` Palmer Dabbelt 2023-02-22 16:17 ` RISC-V Zbb QEMU Boot Failures (was Re: [PATCH v1] RISC-V: take text_mutex during alternative patching) Palmer Dabbelt 2023-02-22 15:00 ` [PATCH v1] RISC-V: take text_mutex during alternative patching patchwork-bot+linux-riscv
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox