* [PATCH 0/3] ARM: vfp: Introduce vfp_lock() for VFP locking.
@ 2023-06-15 10:16 Sebastian Andrzej Siewior
2023-06-15 10:16 ` [PATCH 1/3] ARM: vfp: Provide " Sebastian Andrzej Siewior
` (3 more replies)
0 siblings, 4 replies; 19+ messages in thread
From: Sebastian Andrzej Siewior @ 2023-06-15 10:16 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Russell King, Ard Biesheuvel, Thomas Gleixner
There was a bug report on PREEMPT_RT which made me look into VFP locking
on ARM. The usage of local_bh_disable() to ensure exclusive access to
the VFP unit is not working on PREEMPT_RT because the softirq context is
preemptible.
This series introduces vfp_lock() which does the right thing.
This series depends on Ard's rewrite of the VFP exception handling:
ARM: convert VFP exception handling to C code
https://lore.kernel.org/20230522080310.502250-1-ardb@kernel.org
Sebastian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 1/3] ARM: vfp: Provide vfp_lock() for VFP locking. 2023-06-15 10:16 [PATCH 0/3] ARM: vfp: Introduce vfp_lock() for VFP locking Sebastian Andrzej Siewior @ 2023-06-15 10:16 ` Sebastian Andrzej Siewior 2023-06-15 10:16 ` [PATCH 2/3] ARM: vfp: Use vfp_lock() in vfp_sync_hwstate() Sebastian Andrzej Siewior ` (2 subsequent siblings) 3 siblings, 0 replies; 19+ messages in thread From: Sebastian Andrzej Siewior @ 2023-06-15 10:16 UTC (permalink / raw) To: linux-arm-kernel Cc: Russell King, Ard Biesheuvel, Thomas Gleixner, Sebastian Andrzej Siewior kernel_neon_begin() uses local_bh_disable() to ensure exclusive access to the VFP unit. This is broken on PREEMPT_RT because a BH disabled section remains preemptible on PREEMPT_RT. Introduce vfp_lock() which uses local_bh_disable() and preempt_disable() on PREEMPT_RT. Since softirqs are processed always in thread context, disabling preemption is enough to ensure that the current context won't get interrupted by something that is using the VFP. Use it in kernel_neon_begin(). Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> --- arch/arm/vfp/vfpmodule.c | 32 ++++++++++++++++++++++++++++++-- 1 file changed, 30 insertions(+), 2 deletions(-) diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c index 58a9442add24b..0a21e13095809 100644 --- a/arch/arm/vfp/vfpmodule.c +++ b/arch/arm/vfp/vfpmodule.c @@ -54,6 +54,34 @@ extern unsigned int VFP_arch_feroceon __alias(VFP_arch); */ union vfp_state *vfp_current_hw_state[NR_CPUS]; +/* + * Claim ownership of the VFP unit. + * + * The caller may change VFP registers until vfp_unlock() is called. + * + * local_bh_disable() is used to disable preemption and to disable VFP + * processing in softirq context. On PREEMPT_RT kernels local_bh_disable() is + * not sufficient because it only serializes soft interrupt related sections + * via a local lock, but stays preemptible. Disabling preemption is the right + * choice here as bottom half processing is always in thread context on RT + * kernels so it implicitly prevents bottom half processing as well. + */ +static void vfp_lock(void) +{ + if (!IS_ENABLED(CONFIG_PREEMPT_RT)) + local_bh_disable(); + else + preempt_disable(); +} + +static void vfp_unlock(void) +{ + if (!IS_ENABLED(CONFIG_PREEMPT_RT)) + local_bh_enable(); + else + preempt_enable(); +} + /* * Is 'thread's most up to date state stored in this CPUs hardware? * Must be called from non-preemptible context. @@ -818,7 +846,7 @@ void kernel_neon_begin(void) unsigned int cpu; u32 fpexc; - local_bh_disable(); + vfp_lock(); /* * Kernel mode NEON is only allowed outside of hardirq context with @@ -849,7 +877,7 @@ void kernel_neon_end(void) { /* Disable the NEON/VFP unit. */ fmxr(FPEXC, fmrx(FPEXC) & ~FPEXC_EN); - local_bh_enable(); + vfp_unlock(); } EXPORT_SYMBOL(kernel_neon_end); -- 2.40.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH 2/3] ARM: vfp: Use vfp_lock() in vfp_sync_hwstate(). 2023-06-15 10:16 [PATCH 0/3] ARM: vfp: Introduce vfp_lock() for VFP locking Sebastian Andrzej Siewior 2023-06-15 10:16 ` [PATCH 1/3] ARM: vfp: Provide " Sebastian Andrzej Siewior @ 2023-06-15 10:16 ` Sebastian Andrzej Siewior 2023-06-15 10:16 ` [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry() Sebastian Andrzej Siewior 2023-09-07 13:53 ` [PATCH 0/3] ARM: vfp: Introduce vfp_lock() for VFP locking Ard Biesheuvel 3 siblings, 0 replies; 19+ messages in thread From: Sebastian Andrzej Siewior @ 2023-06-15 10:16 UTC (permalink / raw) To: linux-arm-kernel Cc: Russell King, Ard Biesheuvel, Thomas Gleixner, Sebastian Andrzej Siewior vfp_sync_hwstate() uses preempt_disable() followed by local_bh_disable() to ensure that it won't get interrupted while checking the VFP state. This harms PREEMPT_RT because softirq handling can get preempted and local_bh_disable() synchronizes the related section with a sleeping lock which does not work with disabled preemption. Use the vfp_lock() to synchronize the access. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> --- arch/arm/vfp/vfpmodule.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c index 0a21e13095809..524aec81134ba 100644 --- a/arch/arm/vfp/vfpmodule.c +++ b/arch/arm/vfp/vfpmodule.c @@ -539,11 +539,9 @@ static inline void vfp_pm_init(void) { } */ void vfp_sync_hwstate(struct thread_info *thread) { - unsigned int cpu = get_cpu(); + vfp_lock(); - local_bh_disable(); - - if (vfp_state_in_hw(cpu, thread)) { + if (vfp_state_in_hw(raw_smp_processor_id(), thread)) { u32 fpexc = fmrx(FPEXC); /* @@ -554,8 +552,7 @@ void vfp_sync_hwstate(struct thread_info *thread) fmxr(FPEXC, fpexc); } - local_bh_enable(); - put_cpu(); + vfp_unlock(); } /* Ensure that the thread reloads the hardware VFP state on the next use. */ -- 2.40.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry(). 2023-06-15 10:16 [PATCH 0/3] ARM: vfp: Introduce vfp_lock() for VFP locking Sebastian Andrzej Siewior 2023-06-15 10:16 ` [PATCH 1/3] ARM: vfp: Provide " Sebastian Andrzej Siewior 2023-06-15 10:16 ` [PATCH 2/3] ARM: vfp: Use vfp_lock() in vfp_sync_hwstate() Sebastian Andrzej Siewior @ 2023-06-15 10:16 ` Sebastian Andrzej Siewior 2023-06-27 10:22 ` Ard Biesheuvel 2023-09-07 13:53 ` [PATCH 0/3] ARM: vfp: Introduce vfp_lock() for VFP locking Ard Biesheuvel 3 siblings, 1 reply; 19+ messages in thread From: Sebastian Andrzej Siewior @ 2023-06-15 10:16 UTC (permalink / raw) To: linux-arm-kernel Cc: Russell King, Ard Biesheuvel, Thomas Gleixner, Sebastian Andrzej Siewior vfp_entry() is invoked from exception handler and is fully preemptible. It uses local_bh_disable() to remain uninterrupted while checking the VFP state. This is not working on PREEMPT_RT because local_bh_disable() synchronizes the relevant section but the context remains fully preemptible. Use vfp_lock() for uninterrupted access. VFP_bounce() is invoked from within vfp_entry() and may send a signal. Sending a signal uses spinlock_t which becomes a sleeping lock on PREEMPT_RT and must not be acquired within a preempt-disabled section. Move the vfp_raise_sigfpe() block outside of the preempt-disabled section. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> --- arch/arm/vfp/vfpmodule.c | 33 ++++++++++++++++++++------------- 1 file changed, 20 insertions(+), 13 deletions(-) diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c index 524aec81134ba..67d7042bc3d5c 100644 --- a/arch/arm/vfp/vfpmodule.c +++ b/arch/arm/vfp/vfpmodule.c @@ -267,7 +267,7 @@ static void vfp_panic(char *reason, u32 inst) /* * Process bitmask of exception conditions. */ -static void vfp_raise_exceptions(u32 exceptions, u32 inst, u32 fpscr, struct pt_regs *regs) +static int vfp_raise_exceptions(u32 exceptions, u32 inst, u32 fpscr) { int si_code = 0; @@ -275,8 +275,7 @@ static void vfp_raise_exceptions(u32 exceptions, u32 inst, u32 fpscr, struct pt_ if (exceptions == VFP_EXCEPTION_ERROR) { vfp_panic("unhandled bounce", inst); - vfp_raise_sigfpe(FPE_FLTINV, regs); - return; + return FPE_FLTINV; } /* @@ -304,8 +303,7 @@ static void vfp_raise_exceptions(u32 exceptions, u32 inst, u32 fpscr, struct pt_ RAISE(FPSCR_OFC, FPSCR_OFE, FPE_FLTOVF); RAISE(FPSCR_IOC, FPSCR_IOE, FPE_FLTINV); - if (si_code) - vfp_raise_sigfpe(si_code, regs); + return si_code; } /* @@ -351,6 +349,8 @@ static u32 vfp_emulate_instruction(u32 inst, u32 fpscr, struct pt_regs *regs) static void VFP_bounce(u32 trigger, u32 fpexc, struct pt_regs *regs) { u32 fpscr, orig_fpscr, fpsid, exceptions; + int si_code2 = 0; + int si_code = 0; pr_debug("VFP: bounce: trigger %08x fpexc %08x\n", trigger, fpexc); @@ -396,8 +396,8 @@ static void VFP_bounce(u32 trigger, u32 fpexc, struct pt_regs *regs) * unallocated VFP instruction but with FPSCR.IXE set and not * on VFP subarch 1. */ - vfp_raise_exceptions(VFP_EXCEPTION_ERROR, trigger, fpscr, regs); - return; + si_code = vfp_raise_exceptions(VFP_EXCEPTION_ERROR, trigger, fpscr); + goto exit; } /* @@ -421,14 +421,14 @@ static void VFP_bounce(u32 trigger, u32 fpexc, struct pt_regs *regs) */ exceptions = vfp_emulate_instruction(trigger, fpscr, regs); if (exceptions) - vfp_raise_exceptions(exceptions, trigger, orig_fpscr, regs); + si_code2 = vfp_raise_exceptions(exceptions, trigger, orig_fpscr); /* * If there isn't a second FP instruction, exit now. Note that * the FPEXC.FP2V bit is valid only if FPEXC.EX is 1. */ if ((fpexc & (FPEXC_EX | FPEXC_FP2V)) != (FPEXC_EX | FPEXC_FP2V)) - return; + goto exit; /* * The barrier() here prevents fpinst2 being read @@ -440,7 +440,13 @@ static void VFP_bounce(u32 trigger, u32 fpexc, struct pt_regs *regs) emulate: exceptions = vfp_emulate_instruction(trigger, orig_fpscr, regs); if (exceptions) - vfp_raise_exceptions(exceptions, trigger, orig_fpscr, regs); + si_code = vfp_raise_exceptions(exceptions, trigger, orig_fpscr); +exit: + vfp_unlock(); + if (si_code2) + vfp_raise_sigfpe(si_code2, regs); + if (si_code) + vfp_raise_sigfpe(si_code, regs); } static void vfp_enable(void *unused) @@ -707,7 +713,7 @@ static int vfp_support_entry(struct pt_regs *regs, u32 trigger) if (!user_mode(regs)) return vfp_kmode_exception(regs, trigger); - local_bh_disable(); + vfp_lock(); fpexc = fmrx(FPEXC); /* @@ -772,6 +778,7 @@ static int vfp_support_entry(struct pt_regs *regs, u32 trigger) * replay the instruction that trapped. */ fmxr(FPEXC, fpexc); + vfp_unlock(); } else { /* Check for synchronous or asynchronous exceptions */ if (!(fpexc & (FPEXC_EX | FPEXC_DEX))) { @@ -786,17 +793,17 @@ static int vfp_support_entry(struct pt_regs *regs, u32 trigger) if (!(fpscr & FPSCR_IXE)) { if (!(fpscr & FPSCR_LENGTH_MASK)) { pr_debug("not VFP\n"); - local_bh_enable(); + vfp_unlock(); return -ENOEXEC; } fpexc |= FPEXC_DEX; } } bounce: regs->ARM_pc += 4; + /* VFP_bounce() will invoke vfp_unlock() */ VFP_bounce(trigger, fpexc, regs); } - local_bh_enable(); return 0; } -- 2.40.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry(). 2023-06-15 10:16 ` [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry() Sebastian Andrzej Siewior @ 2023-06-27 10:22 ` Ard Biesheuvel 2023-06-27 12:41 ` Sebastian Andrzej Siewior 0 siblings, 1 reply; 19+ messages in thread From: Ard Biesheuvel @ 2023-06-27 10:22 UTC (permalink / raw) To: Sebastian Andrzej Siewior; +Cc: linux-arm-kernel, Russell King, Thomas Gleixner On Thu, 15 Jun 2023 at 12:17, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote: > > vfp_entry() is invoked from exception handler and is fully preemptible. > It uses local_bh_disable() to remain uninterrupted while checking the > VFP state. > This is not working on PREEMPT_RT because local_bh_disable() > synchronizes the relevant section but the context remains fully > preemptible. > > Use vfp_lock() for uninterrupted access. > > VFP_bounce() is invoked from within vfp_entry() and may send a signal. > Sending a signal uses spinlock_t which becomes a sleeping lock > on PREEMPT_RT and must not be acquired within a preempt-disabled > section. Move the vfp_raise_sigfpe() block outside of the > preempt-disabled section. > Isn't the latter a separate issue that predates the softirq changes? If so, it should be fixed separately too, and backported to -stable (unless nobody uses out-of-tree PREEMPT_RT with those kernels) > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> > --- > arch/arm/vfp/vfpmodule.c | 33 ++++++++++++++++++++------------- > 1 file changed, 20 insertions(+), 13 deletions(-) > > diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c > index 524aec81134ba..67d7042bc3d5c 100644 > --- a/arch/arm/vfp/vfpmodule.c > +++ b/arch/arm/vfp/vfpmodule.c > @@ -267,7 +267,7 @@ static void vfp_panic(char *reason, u32 inst) > /* > * Process bitmask of exception conditions. > */ > -static void vfp_raise_exceptions(u32 exceptions, u32 inst, u32 fpscr, struct pt_regs *regs) > +static int vfp_raise_exceptions(u32 exceptions, u32 inst, u32 fpscr) > { > int si_code = 0; > > @@ -275,8 +275,7 @@ static void vfp_raise_exceptions(u32 exceptions, u32 inst, u32 fpscr, struct pt_ > > if (exceptions == VFP_EXCEPTION_ERROR) { > vfp_panic("unhandled bounce", inst); > - vfp_raise_sigfpe(FPE_FLTINV, regs); > - return; > + return FPE_FLTINV; > } > > /* > @@ -304,8 +303,7 @@ static void vfp_raise_exceptions(u32 exceptions, u32 inst, u32 fpscr, struct pt_ > RAISE(FPSCR_OFC, FPSCR_OFE, FPE_FLTOVF); > RAISE(FPSCR_IOC, FPSCR_IOE, FPE_FLTINV); > > - if (si_code) > - vfp_raise_sigfpe(si_code, regs); > + return si_code; > } > > /* > @@ -351,6 +349,8 @@ static u32 vfp_emulate_instruction(u32 inst, u32 fpscr, struct pt_regs *regs) > static void VFP_bounce(u32 trigger, u32 fpexc, struct pt_regs *regs) > { > u32 fpscr, orig_fpscr, fpsid, exceptions; > + int si_code2 = 0; > + int si_code = 0; > > pr_debug("VFP: bounce: trigger %08x fpexc %08x\n", trigger, fpexc); > > @@ -396,8 +396,8 @@ static void VFP_bounce(u32 trigger, u32 fpexc, struct pt_regs *regs) > * unallocated VFP instruction but with FPSCR.IXE set and not > * on VFP subarch 1. > */ > - vfp_raise_exceptions(VFP_EXCEPTION_ERROR, trigger, fpscr, regs); > - return; > + si_code = vfp_raise_exceptions(VFP_EXCEPTION_ERROR, trigger, fpscr); > + goto exit; > } > > /* > @@ -421,14 +421,14 @@ static void VFP_bounce(u32 trigger, u32 fpexc, struct pt_regs *regs) > */ > exceptions = vfp_emulate_instruction(trigger, fpscr, regs); > if (exceptions) > - vfp_raise_exceptions(exceptions, trigger, orig_fpscr, regs); > + si_code2 = vfp_raise_exceptions(exceptions, trigger, orig_fpscr); > > /* > * If there isn't a second FP instruction, exit now. Note that > * the FPEXC.FP2V bit is valid only if FPEXC.EX is 1. > */ > if ((fpexc & (FPEXC_EX | FPEXC_FP2V)) != (FPEXC_EX | FPEXC_FP2V)) > - return; > + goto exit; > > /* > * The barrier() here prevents fpinst2 being read > @@ -440,7 +440,13 @@ static void VFP_bounce(u32 trigger, u32 fpexc, struct pt_regs *regs) > emulate: > exceptions = vfp_emulate_instruction(trigger, orig_fpscr, regs); > if (exceptions) > - vfp_raise_exceptions(exceptions, trigger, orig_fpscr, regs); > + si_code = vfp_raise_exceptions(exceptions, trigger, orig_fpscr); > +exit: > + vfp_unlock(); > + if (si_code2) > + vfp_raise_sigfpe(si_code2, regs); > + if (si_code) > + vfp_raise_sigfpe(si_code, regs); > } > > static void vfp_enable(void *unused) > @@ -707,7 +713,7 @@ static int vfp_support_entry(struct pt_regs *regs, u32 trigger) > if (!user_mode(regs)) > return vfp_kmode_exception(regs, trigger); > > - local_bh_disable(); > + vfp_lock(); > fpexc = fmrx(FPEXC); > > /* > @@ -772,6 +778,7 @@ static int vfp_support_entry(struct pt_regs *regs, u32 trigger) > * replay the instruction that trapped. > */ > fmxr(FPEXC, fpexc); > + vfp_unlock(); > } else { > /* Check for synchronous or asynchronous exceptions */ > if (!(fpexc & (FPEXC_EX | FPEXC_DEX))) { > @@ -786,17 +793,17 @@ static int vfp_support_entry(struct pt_regs *regs, u32 trigger) > if (!(fpscr & FPSCR_IXE)) { > if (!(fpscr & FPSCR_LENGTH_MASK)) { > pr_debug("not VFP\n"); > - local_bh_enable(); > + vfp_unlock(); > return -ENOEXEC; > } > fpexc |= FPEXC_DEX; > } > } > bounce: regs->ARM_pc += 4; > + /* VFP_bounce() will invoke vfp_unlock() */ > VFP_bounce(trigger, fpexc, regs); > } > > - local_bh_enable(); > return 0; > } > > -- > 2.40.1 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry(). 2023-06-27 10:22 ` Ard Biesheuvel @ 2023-06-27 12:41 ` Sebastian Andrzej Siewior 2023-06-27 12:57 ` Ard Biesheuvel 0 siblings, 1 reply; 19+ messages in thread From: Sebastian Andrzej Siewior @ 2023-06-27 12:41 UTC (permalink / raw) To: Ard Biesheuvel; +Cc: linux-arm-kernel, Russell King, Thomas Gleixner On 2023-06-27 12:22:23 [+0200], Ard Biesheuvel wrote: > On Thu, 15 Jun 2023 at 12:17, Sebastian Andrzej Siewior > <bigeasy@linutronix.de> wrote: > > > > vfp_entry() is invoked from exception handler and is fully preemptible. > > It uses local_bh_disable() to remain uninterrupted while checking the > > VFP state. > > This is not working on PREEMPT_RT because local_bh_disable() > > synchronizes the relevant section but the context remains fully > > preemptible. > > > > Use vfp_lock() for uninterrupted access. > > > > VFP_bounce() is invoked from within vfp_entry() and may send a signal. > > Sending a signal uses spinlock_t which becomes a sleeping lock > > on PREEMPT_RT and must not be acquired within a preempt-disabled > > section. Move the vfp_raise_sigfpe() block outside of the > > preempt-disabled section. > > > > Isn't the latter a separate issue that predates the softirq changes? > If so, it should be fixed separately too, and backported to -stable > (unless nobody uses out-of-tree PREEMPT_RT with those kernels) This only affects the PREEMPT_RT tree and once this is settled I would ask to backport the PREEMPT_RT related fixes within the preempt-rt stable trees and not bother the official stable trees. Thanks for noting ;) Sebastian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry(). 2023-06-27 12:41 ` Sebastian Andrzej Siewior @ 2023-06-27 12:57 ` Ard Biesheuvel 2023-06-27 13:06 ` Sebastian Andrzej Siewior 0 siblings, 1 reply; 19+ messages in thread From: Ard Biesheuvel @ 2023-06-27 12:57 UTC (permalink / raw) To: Sebastian Andrzej Siewior; +Cc: linux-arm-kernel, Russell King, Thomas Gleixner On Tue, 27 Jun 2023 at 14:41, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote: > > On 2023-06-27 12:22:23 [+0200], Ard Biesheuvel wrote: > > On Thu, 15 Jun 2023 at 12:17, Sebastian Andrzej Siewior > > <bigeasy@linutronix.de> wrote: > > > > > > vfp_entry() is invoked from exception handler and is fully preemptible. > > > It uses local_bh_disable() to remain uninterrupted while checking the > > > VFP state. > > > This is not working on PREEMPT_RT because local_bh_disable() > > > synchronizes the relevant section but the context remains fully > > > preemptible. > > > > > > Use vfp_lock() for uninterrupted access. > > > > > > VFP_bounce() is invoked from within vfp_entry() and may send a signal. > > > Sending a signal uses spinlock_t which becomes a sleeping lock > > > on PREEMPT_RT and must not be acquired within a preempt-disabled > > > section. Move the vfp_raise_sigfpe() block outside of the > > > preempt-disabled section. > > > > > > > Isn't the latter a separate issue that predates the softirq changes? > > If so, it should be fixed separately too, and backported to -stable > > (unless nobody uses out-of-tree PREEMPT_RT with those kernels) > > This only affects the PREEMPT_RT tree and once this is settled I would > ask to backport the PREEMPT_RT related fixes within the preempt-rt > stable trees and not bother the official stable trees. > > Thanks for noting ;) > OK, so would it make sense to split this off into a separate patch, and combine all the vfp_lock/unlock replacements into a second patch. Note that Russell didn't pull my VFP work so it won't be landing in v6.5. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry(). 2023-06-27 12:57 ` Ard Biesheuvel @ 2023-06-27 13:06 ` Sebastian Andrzej Siewior 2023-06-27 13:22 ` Russell King (Oracle) 0 siblings, 1 reply; 19+ messages in thread From: Sebastian Andrzej Siewior @ 2023-06-27 13:06 UTC (permalink / raw) To: Ard Biesheuvel; +Cc: linux-arm-kernel, Russell King, Thomas Gleixner On 2023-06-27 14:57:38 [+0200], Ard Biesheuvel wrote: > > OK, so would it make sense to split this off into a separate patch, > and combine all the vfp_lock/unlock replacements into a second patch. If you want I can split it. Given that the code in v6.1 looks different, I'm not sure if I can apply it as-it or need to adapt it anyway. > Note that Russell didn't pull my VFP work so it won't be landing in v6.5. Good, or not. Please keep me in the loop if you repost so I can rebase accordingly if needed. Sebastian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry(). 2023-06-27 13:06 ` Sebastian Andrzej Siewior @ 2023-06-27 13:22 ` Russell King (Oracle) 2023-06-27 13:26 ` Ard Biesheuvel 2023-06-27 13:34 ` Sebastian Andrzej Siewior 0 siblings, 2 replies; 19+ messages in thread From: Russell King (Oracle) @ 2023-06-27 13:22 UTC (permalink / raw) To: Sebastian Andrzej Siewior Cc: Ard Biesheuvel, linux-arm-kernel, Thomas Gleixner On Tue, Jun 27, 2023 at 03:06:02PM +0200, Sebastian Andrzej Siewior wrote: > On 2023-06-27 14:57:38 [+0200], Ard Biesheuvel wrote: > > > > OK, so would it make sense to split this off into a separate patch, > > and combine all the vfp_lock/unlock replacements into a second patch. > > If you want I can split it. Given that the code in v6.1 looks different, > I'm not sure if I can apply it as-it or need to adapt it anyway. > > > Note that Russell didn't pull my VFP work so it won't be landing in v6.5. > Good, or not. Please keep me in the loop if you repost so I can rebase > accordingly if needed. Probably a good thing if the problem you have is caused by Ard's series... as the patch system is down for the long term until Debian fix their mariadb security regression which prevents a server requiring a minimum of TLS v1.2 accepting connections from Debian Bookworm systems (which regress from supporting TLS v1.3 to a maximum of TLS v1.1). I reported this as a bug to the debian BTS last week, and as I have come to expect from useless waste of space distro bug tracking systems, there has been zero reaction - and as the bug has already been reported by others, and they've been fobbed off by the package maintainer, I am not hopeful that this regression will ever be fixed. It seems to me that Debian is ripe for having a CVE raised against Bookworm for the regression, especially as TLS v1.1 is now regarded as vulnerable due to downgrade attacks - and maybe that will make Debian sit up and take notice. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry(). 2023-06-27 13:22 ` Russell King (Oracle) @ 2023-06-27 13:26 ` Ard Biesheuvel 2023-06-27 13:32 ` Russell King (Oracle) 2023-06-27 13:34 ` Sebastian Andrzej Siewior 1 sibling, 1 reply; 19+ messages in thread From: Ard Biesheuvel @ 2023-06-27 13:26 UTC (permalink / raw) To: Russell King (Oracle) Cc: Sebastian Andrzej Siewior, linux-arm-kernel, Thomas Gleixner On Tue, 27 Jun 2023 at 15:22, Russell King (Oracle) <linux@armlinux.org.uk> wrote: > > On Tue, Jun 27, 2023 at 03:06:02PM +0200, Sebastian Andrzej Siewior wrote: > > On 2023-06-27 14:57:38 [+0200], Ard Biesheuvel wrote: > > > > > > OK, so would it make sense to split this off into a separate patch, > > > and combine all the vfp_lock/unlock replacements into a second patch. > > > > If you want I can split it. Given that the code in v6.1 looks different, > > I'm not sure if I can apply it as-it or need to adapt it anyway. > > > > > Note that Russell didn't pull my VFP work so it won't be landing in v6.5. > > Good, or not. Please keep me in the loop if you repost so I can rebase > > accordingly if needed. > > Probably a good thing if the problem you have is caused by Ard's > series... No, they are independent. Note that PREEMPT_RT for ARM is not in mainline, so this is not a regression of any kind for mainline itself. I suggested to Sebastian to rebase his changes on top of my PR, but that seems to have fallen between the cracks. > as the patch system is down for the long term until Debian > fix their mariadb security regression which prevents a server requiring > a minimum of TLS v1.2 accepting connections from Debian Bookworm > systems (which regress from supporting TLS v1.3 to a maximum of TLS > v1.1). > > I reported this as a bug to the debian BTS last week, and as I have > come to expect from useless waste of space distro bug tracking systems, > there has been zero reaction - and as the bug has already been reported > by others, and they've been fobbed off by the package maintainer, I am > not hopeful that this regression will ever be fixed. > > It seems to me that Debian is ripe for having a CVE raised against > Bookworm for the regression, especially as TLS v1.1 is now regarded > as vulnerable due to downgrade attacks - and maybe that will make > Debian sit up and take notice. > Does this mean the ARM tree is closed for business a the moment? Is there no way to carry on without the patch system? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry(). 2023-06-27 13:26 ` Ard Biesheuvel @ 2023-06-27 13:32 ` Russell King (Oracle) 2023-06-27 14:40 ` Russell King (Oracle) 0 siblings, 1 reply; 19+ messages in thread From: Russell King (Oracle) @ 2023-06-27 13:32 UTC (permalink / raw) To: Ard Biesheuvel Cc: Sebastian Andrzej Siewior, linux-arm-kernel, Thomas Gleixner On Tue, Jun 27, 2023 at 03:26:16PM +0200, Ard Biesheuvel wrote: > On Tue, 27 Jun 2023 at 15:22, Russell King (Oracle) > <linux@armlinux.org.uk> wrote: > > as the patch system is down for the long term until Debian > > fix their mariadb security regression which prevents a server requiring > > a minimum of TLS v1.2 accepting connections from Debian Bookworm > > systems (which regress from supporting TLS v1.3 to a maximum of TLS > > v1.1). > > > > I reported this as a bug to the debian BTS last week, and as I have > > come to expect from useless waste of space distro bug tracking systems, > > there has been zero reaction - and as the bug has already been reported > > by others, and they've been fobbed off by the package maintainer, I am > > not hopeful that this regression will ever be fixed. > > > > It seems to me that Debian is ripe for having a CVE raised against > > Bookworm for the regression, especially as TLS v1.1 is now regarded > > as vulnerable due to downgrade attacks - and maybe that will make > > Debian sit up and take notice. > > > > Does this mean the ARM tree is closed for business a the moment? Is > there no way to carry on without the patch system? Only if you want to see just how utterly terrible I am trying to pick patches off the mailing list... IMHO, the better thing would be to apply pressure to Debian to get them to at least recognise their cockup, so that then we have some idea when stuff can be resurected. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry(). 2023-06-27 13:32 ` Russell King (Oracle) @ 2023-06-27 14:40 ` Russell King (Oracle) 2023-06-27 15:02 ` Russell King (Oracle) 0 siblings, 1 reply; 19+ messages in thread From: Russell King (Oracle) @ 2023-06-27 14:40 UTC (permalink / raw) To: Ard Biesheuvel Cc: Sebastian Andrzej Siewior, linux-arm-kernel, Thomas Gleixner On Tue, Jun 27, 2023 at 02:32:39PM +0100, Russell King (Oracle) wrote: > On Tue, Jun 27, 2023 at 03:26:16PM +0200, Ard Biesheuvel wrote: > > On Tue, 27 Jun 2023 at 15:22, Russell King (Oracle) > > <linux@armlinux.org.uk> wrote: > > > as the patch system is down for the long term until Debian > > > fix their mariadb security regression which prevents a server requiring > > > a minimum of TLS v1.2 accepting connections from Debian Bookworm > > > systems (which regress from supporting TLS v1.3 to a maximum of TLS > > > v1.1). > > > > > > I reported this as a bug to the debian BTS last week, and as I have > > > come to expect from useless waste of space distro bug tracking systems, > > > there has been zero reaction - and as the bug has already been reported > > > by others, and they've been fobbed off by the package maintainer, I am > > > not hopeful that this regression will ever be fixed. > > > > > > It seems to me that Debian is ripe for having a CVE raised against > > > Bookworm for the regression, especially as TLS v1.1 is now regarded > > > as vulnerable due to downgrade attacks - and maybe that will make > > > Debian sit up and take notice. > > > > > > > Does this mean the ARM tree is closed for business a the moment? Is > > there no way to carry on without the patch system? > > Only if you want to see just how utterly terrible I am trying to pick > patches off the mailing list... > > IMHO, the better thing would be to apply pressure to Debian to get > them to at least recognise their cockup, so that then we have some > idea when stuff can be resurected. Doing a bit more digging, it seems my /usr/bin/mysql was leading me somewhat astray - it was mariadb-client-core-10.1 despite following the recommended debian upgrade path over the years - so that dates from a time when TLS v1.1 was the max. However, that's just a distraction. libdbd-mysql-perl refuses to even attempt to connect - it seems to bail out before even trying. The confusing thing is that /usr/bin/mysql was reporting error 2026, and when one traces libdbd-mysql-perl, the trace file also reports error 2026: imp_dbh->bind_type_guessing: 0 imp_dbh->use_server_side_prepare: 0 imp_dbh->disable_fallback_for_server_prepare: 0 --> do_error SSL connection error: Enforcing SSL encryption is not supported error 2026 recorded: SSL connection error: Enforcing SSL encryption is not supported <-- do_error <> DESTROY(DBI::db=HASH(0x255d118)) ignored for outer handle (inner DBI::db=HASH(0x256ca80) has ref cnt 2) However, these two error numbers, although identical, are totally different. I haven't yet figured out where "error 2026" comes from in libdbd-mysql-perl. _This_ 2026 error comes from libdbd-mysql-perl itself, and after quite a bit of research, it's due to: if (ssl_enforce) { <== true #if defined(HAVE_SSL_MODE_ONLY_REQUIRED) <== not defined ... #elif defined(HAVE_SSL_ENFORCE) <== not defined ... #elif defined(HAVE_SSL_VERIFY) <== defined if (!ssl_verify_also_enforce_ssl()) { set_ssl_error(sock, "Enforcing SSL encryption is not supported"); return NULL; } ssl_verify_also_enforce_ssl() does this: static inline bool ssl_verify_also_enforce_ssl(void) { #ifdef MARIADB_BASE_VERSION my_ulonglong version = mysql_get_client_version(); return ((version >= 50544 && version < 50600) || (version >= 100020 && version < 100100) || version >= 100106); #else return false; #endif } and mocking up a program to print the result from on Bookworm, mysql_get_client_version() gives: Version = 30305 Where does that come from... #define MARIADB_CLIENT_VERSION_STR "10.11.3" #define MARIADB_BASE_VERSION "mariadb-10.11" #define MARIADB_VERSION_ID 101103 #define MYSQL_CONFIG_NAME "my" #define MYSQL_VERSION_ID 101103 #define MYSQL_SERVER_VERSION "10.11.3-MariaDB" #define MARIADB_PACKAGE_VERSION "3.3.5" #define MARIADB_PACKAGE_VERSION_ID 30305 So, mysql_get_client_version() for mariadb reports the mariadb _package_ version, not the mysql version. The same under Bullseye: Version = 100519 #define MARIADB_CLIENT_VERSION_STR "10.5.19" #define MARIADB_BASE_VERSION "mariadb-10.5" #define MARIADB_VERSION_ID 100519 #define MYSQL_CONFIG_NAME "my" #define MYSQL_VERSION_ID 100519 #define MYSQL_SERVER_VERSION "10.5.19-MariaDB" #define MARIADB_PACKAGE_VERSION "3.1.20" #define MARIADB_PACKAGE_VERSION_ID 30120 So, libdbd-mysql-perl believes that mariadb 10.11.3 is ancient compared to mariadb 10.5.19. I think I need to update that bug with this new information - and it points to a mariadb problem, specifically with libmariadb, and not a TLS regression after all. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry(). 2023-06-27 14:40 ` Russell King (Oracle) @ 2023-06-27 15:02 ` Russell King (Oracle) 2023-06-27 17:41 ` Russell King (Oracle) 0 siblings, 1 reply; 19+ messages in thread From: Russell King (Oracle) @ 2023-06-27 15:02 UTC (permalink / raw) To: Ard Biesheuvel Cc: Sebastian Andrzej Siewior, linux-arm-kernel, Thomas Gleixner On Tue, Jun 27, 2023 at 03:40:10PM +0100, Russell King (Oracle) wrote: > On Tue, Jun 27, 2023 at 02:32:39PM +0100, Russell King (Oracle) wrote: > > On Tue, Jun 27, 2023 at 03:26:16PM +0200, Ard Biesheuvel wrote: > > > On Tue, 27 Jun 2023 at 15:22, Russell King (Oracle) > > > <linux@armlinux.org.uk> wrote: > > > > as the patch system is down for the long term until Debian > > > > fix their mariadb security regression which prevents a server requiring > > > > a minimum of TLS v1.2 accepting connections from Debian Bookworm > > > > systems (which regress from supporting TLS v1.3 to a maximum of TLS > > > > v1.1). > > > > > > > > I reported this as a bug to the debian BTS last week, and as I have > > > > come to expect from useless waste of space distro bug tracking systems, > > > > there has been zero reaction - and as the bug has already been reported > > > > by others, and they've been fobbed off by the package maintainer, I am > > > > not hopeful that this regression will ever be fixed. > > > > > > > > It seems to me that Debian is ripe for having a CVE raised against > > > > Bookworm for the regression, especially as TLS v1.1 is now regarded > > > > as vulnerable due to downgrade attacks - and maybe that will make > > > > Debian sit up and take notice. > > > > > > > > > > Does this mean the ARM tree is closed for business a the moment? Is > > > there no way to carry on without the patch system? > > > > Only if you want to see just how utterly terrible I am trying to pick > > patches off the mailing list... > > > > IMHO, the better thing would be to apply pressure to Debian to get > > them to at least recognise their cockup, so that then we have some > > idea when stuff can be resurected. > > Doing a bit more digging, it seems my /usr/bin/mysql was leading me > somewhat astray - it was mariadb-client-core-10.1 despite following > the recommended debian upgrade path over the years - so that dates > from a time when TLS v1.1 was the max. > > However, that's just a distraction. libdbd-mysql-perl refuses to > even attempt to connect - it seems to bail out before even trying. > > The confusing thing is that /usr/bin/mysql was reporting error 2026, > and when one traces libdbd-mysql-perl, the trace file also reports > error 2026: > > imp_dbh->bind_type_guessing: 0 > imp_dbh->use_server_side_prepare: 0 > imp_dbh->disable_fallback_for_server_prepare: 0 > --> do_error > SSL connection error: Enforcing SSL encryption is not supported error 2026 recorded: SSL connection error: Enforcing SSL encryption is not supported > <-- do_error > <> DESTROY(DBI::db=HASH(0x255d118)) ignored for outer handle (inner DBI::db=HASH(0x256ca80) has ref cnt 2) > > However, these two error numbers, although identical, are totally > different. I haven't yet figured out where "error 2026" comes from > in libdbd-mysql-perl. > > _This_ 2026 error comes from libdbd-mysql-perl itself, and after > quite a bit of research, it's due to: > > if (ssl_enforce) { <== true > #if defined(HAVE_SSL_MODE_ONLY_REQUIRED) <== not defined > ... > #elif defined(HAVE_SSL_ENFORCE) <== not defined > ... > #elif defined(HAVE_SSL_VERIFY) <== defined > if (!ssl_verify_also_enforce_ssl()) { > set_ssl_error(sock, "Enforcing SSL encryption is not supported"); > return NULL; > } > > ssl_verify_also_enforce_ssl() does this: > > static inline bool ssl_verify_also_enforce_ssl(void) { > #ifdef MARIADB_BASE_VERSION > my_ulonglong version = mysql_get_client_version(); > return ((version >= 50544 && version < 50600) || (version >= 100020 && version < 100100) || version >= 100106); > #else > return false; > #endif > } > > and mocking up a program to print the result from on Bookworm, > mysql_get_client_version() gives: > > Version = 30305 > > Where does that come from... > > #define MARIADB_CLIENT_VERSION_STR "10.11.3" > #define MARIADB_BASE_VERSION "mariadb-10.11" > #define MARIADB_VERSION_ID 101103 > #define MYSQL_CONFIG_NAME "my" > #define MYSQL_VERSION_ID 101103 > #define MYSQL_SERVER_VERSION "10.11.3-MariaDB" > #define MARIADB_PACKAGE_VERSION "3.3.5" > #define MARIADB_PACKAGE_VERSION_ID 30305 > > So, mysql_get_client_version() for mariadb reports the mariadb _package_ > version, not the mysql version. > > The same under Bullseye: > > Version = 100519 > > #define MARIADB_CLIENT_VERSION_STR "10.5.19" > #define MARIADB_BASE_VERSION "mariadb-10.5" > #define MARIADB_VERSION_ID 100519 > #define MYSQL_CONFIG_NAME "my" > #define MYSQL_VERSION_ID 100519 > #define MYSQL_SERVER_VERSION "10.5.19-MariaDB" > #define MARIADB_PACKAGE_VERSION "3.1.20" > #define MARIADB_PACKAGE_VERSION_ID 30120 > > So, libdbd-mysql-perl believes that mariadb 10.11.3 is ancient compared > to mariadb 10.5.19. > > I think I need to update that bug with this new information - and it > points to a mariadb problem, specifically with libmariadb, and not a > TLS regression after all. And doing more digging... https://github.com/mariadb-corporation/mariadb-connector-c/commit/a37b7c3965706f9a062baaba0c494dd6efb2c306 So, a change in what the mariadb developers thought was a good idea to report though this interface breaks the perl DBD library... and given that it effectively winds-back the value returned from mysql_get_client_version(), who knows if there's now any sane way of testing the numerical result of that function. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry(). 2023-06-27 15:02 ` Russell King (Oracle) @ 2023-06-27 17:41 ` Russell King (Oracle) 2023-07-28 16:19 ` Sebastian Andrzej Siewior 0 siblings, 1 reply; 19+ messages in thread From: Russell King (Oracle) @ 2023-06-27 17:41 UTC (permalink / raw) To: Ard Biesheuvel Cc: Sebastian Andrzej Siewior, linux-arm-kernel, Thomas Gleixner On Tue, Jun 27, 2023 at 04:02:04PM +0100, Russell King (Oracle) wrote: > On Tue, Jun 27, 2023 at 03:40:10PM +0100, Russell King (Oracle) wrote: > > On Tue, Jun 27, 2023 at 02:32:39PM +0100, Russell King (Oracle) wrote: > > > On Tue, Jun 27, 2023 at 03:26:16PM +0200, Ard Biesheuvel wrote: > > > > On Tue, 27 Jun 2023 at 15:22, Russell King (Oracle) > > > > <linux@armlinux.org.uk> wrote: > > > > > as the patch system is down for the long term until Debian > > > > > fix their mariadb security regression which prevents a server requiring > > > > > a minimum of TLS v1.2 accepting connections from Debian Bookworm > > > > > systems (which regress from supporting TLS v1.3 to a maximum of TLS > > > > > v1.1). > > > > > > > > > > I reported this as a bug to the debian BTS last week, and as I have > > > > > come to expect from useless waste of space distro bug tracking systems, > > > > > there has been zero reaction - and as the bug has already been reported > > > > > by others, and they've been fobbed off by the package maintainer, I am > > > > > not hopeful that this regression will ever be fixed. > > > > > > > > > > It seems to me that Debian is ripe for having a CVE raised against > > > > > Bookworm for the regression, especially as TLS v1.1 is now regarded > > > > > as vulnerable due to downgrade attacks - and maybe that will make > > > > > Debian sit up and take notice. > > > > > > > > > > > > > Does this mean the ARM tree is closed for business a the moment? Is > > > > there no way to carry on without the patch system? > > > > > > Only if you want to see just how utterly terrible I am trying to pick > > > patches off the mailing list... > > > > > > IMHO, the better thing would be to apply pressure to Debian to get > > > them to at least recognise their cockup, so that then we have some > > > idea when stuff can be resurected. > > > > Doing a bit more digging, it seems my /usr/bin/mysql was leading me > > somewhat astray - it was mariadb-client-core-10.1 despite following > > the recommended debian upgrade path over the years - so that dates > > from a time when TLS v1.1 was the max. > > > > However, that's just a distraction. libdbd-mysql-perl refuses to > > even attempt to connect - it seems to bail out before even trying. > > > > The confusing thing is that /usr/bin/mysql was reporting error 2026, > > and when one traces libdbd-mysql-perl, the trace file also reports > > error 2026: > > > > imp_dbh->bind_type_guessing: 0 > > imp_dbh->use_server_side_prepare: 0 > > imp_dbh->disable_fallback_for_server_prepare: 0 > > --> do_error > > SSL connection error: Enforcing SSL encryption is not supported error 2026 recorded: SSL connection error: Enforcing SSL encryption is not supported > > <-- do_error > > <> DESTROY(DBI::db=HASH(0x255d118)) ignored for outer handle (inner DBI::db=HASH(0x256ca80) has ref cnt 2) > > > > However, these two error numbers, although identical, are totally > > different. I haven't yet figured out where "error 2026" comes from > > in libdbd-mysql-perl. > > > > _This_ 2026 error comes from libdbd-mysql-perl itself, and after > > quite a bit of research, it's due to: > > > > if (ssl_enforce) { <== true > > #if defined(HAVE_SSL_MODE_ONLY_REQUIRED) <== not defined > > ... > > #elif defined(HAVE_SSL_ENFORCE) <== not defined > > ... > > #elif defined(HAVE_SSL_VERIFY) <== defined > > if (!ssl_verify_also_enforce_ssl()) { > > set_ssl_error(sock, "Enforcing SSL encryption is not supported"); > > return NULL; > > } > > > > ssl_verify_also_enforce_ssl() does this: > > > > static inline bool ssl_verify_also_enforce_ssl(void) { > > #ifdef MARIADB_BASE_VERSION > > my_ulonglong version = mysql_get_client_version(); > > return ((version >= 50544 && version < 50600) || (version >= 100020 && version < 100100) || version >= 100106); > > #else > > return false; > > #endif > > } > > > > and mocking up a program to print the result from on Bookworm, > > mysql_get_client_version() gives: > > > > Version = 30305 > > > > Where does that come from... > > > > #define MARIADB_CLIENT_VERSION_STR "10.11.3" > > #define MARIADB_BASE_VERSION "mariadb-10.11" > > #define MARIADB_VERSION_ID 101103 > > #define MYSQL_CONFIG_NAME "my" > > #define MYSQL_VERSION_ID 101103 > > #define MYSQL_SERVER_VERSION "10.11.3-MariaDB" > > #define MARIADB_PACKAGE_VERSION "3.3.5" > > #define MARIADB_PACKAGE_VERSION_ID 30305 > > > > So, mysql_get_client_version() for mariadb reports the mariadb _package_ > > version, not the mysql version. > > > > The same under Bullseye: > > > > Version = 100519 > > > > #define MARIADB_CLIENT_VERSION_STR "10.5.19" > > #define MARIADB_BASE_VERSION "mariadb-10.5" > > #define MARIADB_VERSION_ID 100519 > > #define MYSQL_CONFIG_NAME "my" > > #define MYSQL_VERSION_ID 100519 > > #define MYSQL_SERVER_VERSION "10.5.19-MariaDB" > > #define MARIADB_PACKAGE_VERSION "3.1.20" > > #define MARIADB_PACKAGE_VERSION_ID 30120 > > > > So, libdbd-mysql-perl believes that mariadb 10.11.3 is ancient compared > > to mariadb 10.5.19. > > > > I think I need to update that bug with this new information - and it > > points to a mariadb problem, specifically with libmariadb, and not a > > TLS regression after all. > > And doing more digging... > > https://github.com/mariadb-corporation/mariadb-connector-c/commit/a37b7c3965706f9a062baaba0c494dd6efb2c306 > > So, a change in what the mariadb developers thought was a good idea > to report though this interface breaks the perl DBD library... and > given that it effectively winds-back the value returned from > mysql_get_client_version(), who knows if there's now any sane way of > testing the numerical result of that function. Oh, and this just keeps getting better. Read the entire thread on: https://github.com/mariadb-corporation/mariadb-connector-c/pull/219 Whoever thought it was a good idea that mysql_get_client_version() should suddenly be wound back to a smaller number... clearly wasn't thinking the implications through when users of the library are going to be doing stuff like: https://github.com/perl5-dbi/DBD-mysql/blame/master/dbdimp.h#L107 which is over six years old. It really makes me wonder why we try in the kernel not to regress userspace when userspace people don't themselves seem to "get it" and make idiotic changes like this. Anyway, I've now found what seems to be a workaround - telling perl's DBD driver that SSL is optional turns off enforced SSL, and thus stops the DBD driver checking the library version. Not ideal, but at least it gets stuff working again, while the mariadb people work out how to fix their gigantic cockup. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry(). 2023-06-27 17:41 ` Russell King (Oracle) @ 2023-07-28 16:19 ` Sebastian Andrzej Siewior 0 siblings, 0 replies; 19+ messages in thread From: Sebastian Andrzej Siewior @ 2023-07-28 16:19 UTC (permalink / raw) To: Russell King (Oracle); +Cc: Ard Biesheuvel, linux-arm-kernel, Thomas Gleixner On 2023-06-27 18:41:32 [+0100], Russell King (Oracle) wrote: > Oh, and this just keeps getting better. … In the meantime Ard's patches got applied to http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=devel-stable and I rebased my series on top https://git.kernel.org/pub/scm/linux/kernel/git/bigeasy/staging.git/log/?h=arm_vfp_rmk The patches in this thread do apply. Is there anything I could do? Sebastian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry(). 2023-06-27 13:22 ` Russell King (Oracle) 2023-06-27 13:26 ` Ard Biesheuvel @ 2023-06-27 13:34 ` Sebastian Andrzej Siewior 1 sibling, 0 replies; 19+ messages in thread From: Sebastian Andrzej Siewior @ 2023-06-27 13:34 UTC (permalink / raw) To: Russell King (Oracle); +Cc: Ard Biesheuvel, linux-arm-kernel, Thomas Gleixner On 2023-06-27 14:22:36 [+0100], Russell King (Oracle) wrote: > Probably a good thing if the problem you have is caused by Ard's > series... as the patch system is down for the long term until Debian Ard's previous series (reworking the VFP/softirq and allowing VFP usage from within softirq) broke things for RT or made me aware of another problem. The vfp_bounce() problem was unkown. This series of Ard is completely independent and makes it easier to fix it since the code isn't part in .S and part .c so it made things easier. > fix their mariadb security regression which prevents a server requiring > a minimum of TLS v1.2 accepting connections from Debian Bookworm > systems (which regress from supporting TLS v1.3 to a maximum of TLS > v1.1). > > I reported this as a bug to the debian BTS last week, and as I have > come to expect from useless waste of space distro bug tracking systems, > there has been zero reaction - and as the bug has already been reported > by others, and they've been fobbed off by the package maintainer, I am > not hopeful that this regression will ever be fixed. Do you have a BTS number, I may try to ping folks. > It seems to me that Debian is ripe for having a CVE raised against > Bookworm for the regression, especially as TLS v1.1 is now regarded > as vulnerable due to downgrade attacks - and maybe that will make > Debian sit up and take notice. Sebastian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] ARM: vfp: Introduce vfp_lock() for VFP locking. 2023-06-15 10:16 [PATCH 0/3] ARM: vfp: Introduce vfp_lock() for VFP locking Sebastian Andrzej Siewior ` (2 preceding siblings ...) 2023-06-15 10:16 ` [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry() Sebastian Andrzej Siewior @ 2023-09-07 13:53 ` Ard Biesheuvel 2023-09-26 11:03 ` Sebastian Andrzej Siewior 3 siblings, 1 reply; 19+ messages in thread From: Ard Biesheuvel @ 2023-09-07 13:53 UTC (permalink / raw) To: Sebastian Andrzej Siewior; +Cc: linux-arm-kernel, Russell King, Thomas Gleixner On Thu, 15 Jun 2023 at 12:17, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote: > > > There was a bug report on PREEMPT_RT which made me look into VFP locking > on ARM. The usage of local_bh_disable() to ensure exclusive access to > the VFP unit is not working on PREEMPT_RT because the softirq context is > preemptible. > > This series introduces vfp_lock() which does the right thing. > > This series depends on Ard's rewrite of the VFP exception handling: > ARM: convert VFP exception handling to C code > https://lore.kernel.org/20230522080310.502250-1-ardb@kernel.org > For the series, Reviewed-by: Ard Biesheuvel <ardb@kernel.org> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] ARM: vfp: Introduce vfp_lock() for VFP locking. 2023-09-07 13:53 ` [PATCH 0/3] ARM: vfp: Introduce vfp_lock() for VFP locking Ard Biesheuvel @ 2023-09-26 11:03 ` Sebastian Andrzej Siewior 0 siblings, 0 replies; 19+ messages in thread From: Sebastian Andrzej Siewior @ 2023-09-26 11:03 UTC (permalink / raw) To: Ard Biesheuvel; +Cc: linux-arm-kernel, Russell King, Thomas Gleixner On 2023-09-07 15:53:18 [+0200], Ard Biesheuvel wrote: > > For the series, > > Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Thank you. I'm going to repost this with this tag _and_ the 4 patch series/v2 https://lore.kernel.org/all/20230628080516.798032-1-bigeasy@linutronix.de The v2 has a split of the last patch in the series as asked for in https://lore.kernel.org/all/CAMj1kXHUBvvbWaYZcqCABUA48f41Ja548+aosvpkpBkfpc2oUQ@mail.gmail.com As long as you don't disagree you can move to the next email ;) Sebastian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Preemp-RT kernel builds from 6.3 on fails on Xilinx Zynq 7Z010 @ 2023-05-17 22:05 Ard Biesheuvel 2023-05-19 14:57 ` [PATCH 0/3] ARM: vfp: Fixes for PREEMP_RT Sebastian Andrzej Siewior 0 siblings, 1 reply; 19+ messages in thread From: Ard Biesheuvel @ 2023-05-17 22:05 UTC (permalink / raw) To: Sebastian Andrzej Siewior Cc: Pavel Pisa, linux-rt-users, Pavel Hronek, Thomas Gleixner, Peter Zijlstra On Wed, 17 May 2023 at 16:37, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote: > > On 2023-05-17 13:05:32 [+0200], Ard Biesheuvel wrote: > > For context, these changes give a substantial performance boost on the > > RX path to IPsec or WireGuard using SIMD based software crypto. > > > > > … > > > > Please take a look, and confirm whether or not we still need to drop > > > > the get_cpu() call from vfp_sync_hwstate() > > > > > > Yes, it needs to be dealt with. At the time vfp_sync_hwstate() the > > > context is fully preemptible. So that get_cpu() needs to be removed > > > before local_bh_disable(). But… > > > > > > If I understand the logic right, then the VFP state is saved on context > > > switch and the FPU access is disabled but the content remains and is in > > > sync with vfp_current_hw_state. Upon first usage (after the context > > > switch) in userland there is an exception at which point the access to > > > the FPU is enabled (FPEXC_EX) and the FPU content is loaded unless it is > > > in sync as per vfp_current_hw_state. > > > > > > > Exactly. On UP we lazily preserve the user space FP state, and on SMP > > we always preserve it on a context switch. Then, only when user space > > actually tries to use the SIMD context, the correct data is copied in. > > That way, we don't take the performance hit for tasks that are blocked > > in the kernel. > > > > > That means it relies on disabled preemption while operating on > > > vfp_current_hw_state. > > > > In general, this code relies on preserving/restoring the VFP context > > to/from memory to be a critical section, as it needs to run to > > completion once it is started. > > > > > On PREEMPT_RT softirqs are only handled in process > > > context (for instance at the end of the threaded interrupt). Therefore > > > it is sufficient to disable preemption instead of BH. It would need > > > something like x86's fpregs_lock(). > > > > I think this is not the only issue, to be honest. We cannot preempt > > tasks while they are using the SIMD unit in kernel mode, as the kernel > > mode context is never preserved/restored. So we at least need to > > disable preemption again in kernel_neon_begin() [which now relies on > > BH disable to disable preemption but as you point out, that is only > > the case on !RT] > > > > Given this, I wonder whether supporting kernel mode NEON on PREEMPT_RT > > is worth it to begin with. AIUI, the alternative is to disable both > > preemption and BH when touching the VFP state. > > Only preemption on RT. Right. > So it is debatable if it makes sense to use NEON > on RT. The preempt-off section is limited to PAGE_SIZE due the scatter/ > gather walk if I remember correctly. > This depends on the type of algorithm (skciphers/aeads vs shashes/ahashes) but they generally all have a bounded quantum of work before yielding the NEON (and therefore the CPU). > > > Otherwise vfp_entry() can get preempted after decisions based on > > > vfp_current_hw_state have been made. Also kernel_neon_begin() could get > > > preempted after enabling FPU. I think based on current logic, after > > > kernel_neon_begin() a task can get preempted on PREEMPT_RT and since > > > vfp_current_hw_state is NULL the registers won't be saved and a zero set > > > of registers will be loaded once the neon task gets back on the CPU (it > > > seems that VFP exceptions in kernel mode are treated the same way as > > > those in user mode). > > > > > > What do you think? > > > > > > > Indeed. kernel_neon_begin() no longer disabling preemption is > > definitely wrong on PREEMPT_RT. The question is whether we want to > > untangle this or just make PREEMPT_RT and KERNEL_MODE_NEON mutually > > exclusive. This, by itself, makes quite a lot of sense, actually, > > given that on actual 32-bit hardware, the SIMD speedup is not that > > spectacular (the AES and other crypto instructions, which do give an > > order of magnitude speedup are only implemented on 64-bit cores, which > > usually run a 64-bit kernel). So if real-time behavior is a > > requirement, using ordinary crypto implemented in C (which does not > > require preemption to be disabled) is likely preferred anyway. > > I have no opinion which can be backed up by numbers. So I have no > problem to go along with it and disable KERNEL_MODE_NEON since it is > simpler and the benefit is questionable. > > So patch > - #1 KERNEL_MODE_NEON depends on !RT Actually, given your explanation above, I think this may not be necessary. Given that on !RT, disabling BH implies disabling preemption and on RT disabling preemption implies disabling BH, it should just be a matter of doing one or the other consistently, depending on IS_ENABLED(CONFIG_PREEMPT_RT) > - #2 disable BH followed by preemption in vfp_sync_hwstate() and > vfp_entry(). > Not sure what to do here, given my answer to #1 In most cases where the VFP code disables BH, it is either because an interrupting softirq may enable the SIMD unit and disable it again, which would result in a FP exception when the interrupted context tries to access the registers, or because such an interruption would corrupt the preserved/restored FP state if it occurs while such a preserve/restore is in progress. Maybe the commit log of patch 62b95a7b44d1a30b3a9 sheds some more light here. > if so, let me prepare something unless you want to :) > Don't let me stop you :-) ^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 0/3] ARM: vfp: Fixes for PREEMP_RT 2023-05-17 22:05 Preemp-RT kernel builds from 6.3 on fails on Xilinx Zynq 7Z010 Ard Biesheuvel @ 2023-05-19 14:57 ` Sebastian Andrzej Siewior 2023-05-19 14:57 ` [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry() Sebastian Andrzej Siewior 0 siblings, 1 reply; 19+ messages in thread From: Sebastian Andrzej Siewior @ 2023-05-19 14:57 UTC (permalink / raw) To: Ard Biesheuvel Cc: Pavel Pisa, linux-rt-users, Pavel Hronek, Thomas Gleixner, Peter Zijlstra Hi Ard, On 2023-05-18 00:05:33 [+0200], Ard Biesheuvel wrote: > Don't let me stop you :-) made a small series. It seems to address everything and with your assembly rework it is not a big mess. What do you think? Sebastian ^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry(). 2023-05-19 14:57 ` [PATCH 0/3] ARM: vfp: Fixes for PREEMP_RT Sebastian Andrzej Siewior @ 2023-05-19 14:57 ` Sebastian Andrzej Siewior 0 siblings, 0 replies; 19+ messages in thread From: Sebastian Andrzej Siewior @ 2023-05-19 14:57 UTC (permalink / raw) To: Ard Biesheuvel Cc: Pavel Pisa, linux-rt-users, Pavel Hronek, Thomas Gleixner, Peter Zijlstra, Sebastian Andrzej Siewior vfp_entry() is invoked from exception handler and is fully preemptible. It uses local_bh_disable() to remain uninterrupted while checking the VFP state. This is not working on PREEMPT_RT because local_bh_disable() synchronizes the relevant section but the context remains fully preemptible. Use vfp_lock() for uninterrupted access. VFP_bounce() is invoked from within vfp_entry() and may send a signal. Sending a signal uses spinlock_t which becomes a sleeping lock on PREEMPT_RT and must not be acquired within a preempt-disabled section. Move the vfp_raise_sigfpe() block outside of the preempt-disabled section. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> --- arch/arm/vfp/vfphw.S | 7 ++----- arch/arm/vfp/vfpmodule.c | 30 ++++++++++++++++++++---------- 2 files changed, 22 insertions(+), 15 deletions(-) diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S index a4610d0f32152..860512042bc21 100644 --- a/arch/arm/vfp/vfphw.S +++ b/arch/arm/vfp/vfphw.S @@ -180,10 +180,7 @@ ENTRY(vfp_support_entry) @ always subtract 4 from the following @ instruction address. -local_bh_enable_and_ret: - adr r0, . - mov r1, #SOFTIRQ_DISABLE_OFFSET - b __local_bh_enable_ip @ tail call + b vfp_exit @ tail call look_for_VFP_exceptions: @ Check for synchronous or asynchronous exception @@ -206,7 +203,7 @@ ENTRY(vfp_support_entry) @ not recognised by VFP DBGSTR "not VFP" - b local_bh_enable_and_ret + b vfp_exit @ tail call process_exception: DBGSTR "bounce" diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c index 543dc7f5a27e3..a2745d17e9c71 100644 --- a/arch/arm/vfp/vfpmodule.c +++ b/arch/arm/vfp/vfpmodule.c @@ -267,7 +267,7 @@ static void vfp_panic(char *reason, u32 inst) /* * Process bitmask of exception conditions. */ -static void vfp_raise_exceptions(u32 exceptions, u32 inst, u32 fpscr, struct pt_regs *regs) +static int vfp_raise_exceptions(u32 exceptions, u32 inst, u32 fpscr) { int si_code = 0; @@ -275,8 +275,7 @@ static void vfp_raise_exceptions(u32 exceptions, u32 inst, u32 fpscr, struct pt_ if (exceptions == VFP_EXCEPTION_ERROR) { vfp_panic("unhandled bounce", inst); - vfp_raise_sigfpe(FPE_FLTINV, regs); - return; + return FPE_FLTINV; } /* @@ -304,8 +303,7 @@ static void vfp_raise_exceptions(u32 exceptions, u32 inst, u32 fpscr, struct pt_ RAISE(FPSCR_OFC, FPSCR_OFE, FPE_FLTOVF); RAISE(FPSCR_IOC, FPSCR_IOE, FPE_FLTINV); - if (si_code) - vfp_raise_sigfpe(si_code, regs); + return si_code; } /* @@ -350,6 +348,8 @@ static u32 vfp_emulate_instruction(u32 inst, u32 fpscr, struct pt_regs *regs) void VFP_bounce(u32 trigger, u32 fpexc, struct pt_regs *regs) { u32 fpscr, orig_fpscr, fpsid, exceptions; + int si_code2 = 0; + int si_code = 0; pr_debug("VFP: bounce: trigger %08x fpexc %08x\n", trigger, fpexc); @@ -397,7 +397,7 @@ void VFP_bounce(u32 trigger, u32 fpexc, struct pt_regs *regs) * unallocated VFP instruction but with FPSCR.IXE set and not * on VFP subarch 1. */ - vfp_raise_exceptions(VFP_EXCEPTION_ERROR, trigger, fpscr, regs); + si_code = vfp_raise_exceptions(VFP_EXCEPTION_ERROR, trigger, fpscr); goto exit; } @@ -422,7 +422,7 @@ void VFP_bounce(u32 trigger, u32 fpexc, struct pt_regs *regs) */ exceptions = vfp_emulate_instruction(trigger, fpscr, regs); if (exceptions) - vfp_raise_exceptions(exceptions, trigger, orig_fpscr, regs); + si_code2 = vfp_raise_exceptions(exceptions, trigger, orig_fpscr); /* * If there isn't a second FP instruction, exit now. Note that @@ -441,9 +441,14 @@ void VFP_bounce(u32 trigger, u32 fpexc, struct pt_regs *regs) emulate: exceptions = vfp_emulate_instruction(trigger, orig_fpscr, regs); if (exceptions) - vfp_raise_exceptions(exceptions, trigger, orig_fpscr, regs); + si_code = vfp_raise_exceptions(exceptions, trigger, orig_fpscr); + exit: - local_bh_enable(); + vfp_unlock(); + if (si_code2) + vfp_raise_sigfpe(si_code2, regs); + if (si_code) + vfp_raise_sigfpe(si_code, regs); } static void vfp_enable(void *unused) @@ -684,10 +689,15 @@ asmlinkage void vfp_entry(u32 trigger, struct thread_info *ti, u32 resume_pc, if (unlikely(!have_vfp)) return; - local_bh_disable(); + vfp_lock(); vfp_support_entry(trigger, ti, resume_pc, resume_return_address); } +asmlinkage void vfp_exit(void) +{ + vfp_unlock(); +} + #ifdef CONFIG_KERNEL_MODE_NEON static int vfp_kmode_exception(struct pt_regs *regs, unsigned int instr) -- 2.40.1 ^ permalink raw reply related [flat|nested] 19+ messages in thread
end of thread, other threads:[~2023-09-26 11:04 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-06-15 10:16 [PATCH 0/3] ARM: vfp: Introduce vfp_lock() for VFP locking Sebastian Andrzej Siewior 2023-06-15 10:16 ` [PATCH 1/3] ARM: vfp: Provide " Sebastian Andrzej Siewior 2023-06-15 10:16 ` [PATCH 2/3] ARM: vfp: Use vfp_lock() in vfp_sync_hwstate() Sebastian Andrzej Siewior 2023-06-15 10:16 ` [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry() Sebastian Andrzej Siewior 2023-06-27 10:22 ` Ard Biesheuvel 2023-06-27 12:41 ` Sebastian Andrzej Siewior 2023-06-27 12:57 ` Ard Biesheuvel 2023-06-27 13:06 ` Sebastian Andrzej Siewior 2023-06-27 13:22 ` Russell King (Oracle) 2023-06-27 13:26 ` Ard Biesheuvel 2023-06-27 13:32 ` Russell King (Oracle) 2023-06-27 14:40 ` Russell King (Oracle) 2023-06-27 15:02 ` Russell King (Oracle) 2023-06-27 17:41 ` Russell King (Oracle) 2023-07-28 16:19 ` Sebastian Andrzej Siewior 2023-06-27 13:34 ` Sebastian Andrzej Siewior 2023-09-07 13:53 ` [PATCH 0/3] ARM: vfp: Introduce vfp_lock() for VFP locking Ard Biesheuvel 2023-09-26 11:03 ` Sebastian Andrzej Siewior -- strict thread matches above, loose matches on Subject: below -- 2023-05-17 22:05 Preemp-RT kernel builds from 6.3 on fails on Xilinx Zynq 7Z010 Ard Biesheuvel 2023-05-19 14:57 ` [PATCH 0/3] ARM: vfp: Fixes for PREEMP_RT Sebastian Andrzej Siewior 2023-05-19 14:57 ` [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry() Sebastian Andrzej Siewior
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.