Re: [PATCH v4] arch: rename all internal names __xchg to __arch_xchg
On Thu, Jan 5, 2023 at 10:54 AM Andrzej Hajda wrote:
> __xchg will be used for non-atomic xchg macro.
>
> Signed-off-by: Andrzej Hajda
> Reviewed-by: Arnd Bergmann
> ---
> v2: squashed all arch patches into one
> v3: fixed alpha/xchg_local, thx to l...@intel.com
> v4: adjusted indentation (Heiko)
> arch/m68k/include/asm/cmpxchg.h | 6 +++---
Acked-by: Geert Uytterhoeven [m68k]
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: align child stack in clone
On 21/12/22 13:19, Pavel.Kozlov--- via Libc-alpha wrote: > From: Pavel Kozlov > > The ARCv2 ABI requires 4 byte stack pointer alignment. Don't allow to > use unaligned child stack in clone. As the stack grows down, > align it down. > > This was pointed by misc/tst-misalign-clone-internal and > misc/tst-misalign-clone tests. Stack alignmet fixes these tests > fails. LGTM, although I can't really test it since the Synopsys qemu tree does not have qemu-user support [1]. Reviewed-by: Adhemerval Zanella [1] https://github.com/foss-for-synopsys-dwc-arc-processors/qemu > --- > sysdeps/unix/sysv/linux/arc/clone.S | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/sysdeps/unix/sysv/linux/arc/clone.S > b/sysdeps/unix/sysv/linux/arc/clone.S > index bd924890844a..f32c83f17a65 100644 > --- a/sysdeps/unix/sysv/linux/arc/clone.S > +++ b/sysdeps/unix/sysv/linux/arc/clone.S > @@ -41,6 +41,7 @@ > > ENTRY (__clone) > cmp r0, 0 /* @fn can't be NULL. */ > + and r1,r1,-4/* @child_stack be 4 bytes aligned per ABI. */ > cmp.ne r1, 0 /* @child_stack can't be NULL. */ > bz L (__sys_err) > ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC:fpu: add extra capability check before use of sqrt and fma builtins
On 21/12/22 13:28, Pavel.Kozlov--- via Libc-alpha wrote: > From: Pavel Kozlov > > Add extra check for compiler definitions to ensure that compiler provides > sqrt and fma hw fpu instructions else use software implementation. > > As divide/sqrt and FMA hw support from CPU side is optional, > the compiler can be configured by options to generate hw FPU instructions, > but without use of FDDIV, FDSQRT, FSDIV, FSSQRT, FDMADD and FSMADD > instructions. In this case __builtin_sqrt and __builtin_sqrtf provided by > compiler can't be used inside the glibc code, as these builtins are used > in implementations of sqrt() and sqrtf() functions but at the same time > these builtins unfold to sqrt() and sqrtf(). So it is possible to receive > code like that: > > 0001c4b4 <__ieee754_sqrtf>: >1c4b4:0001 b 0 ;1c4b4 <__ieee754_sqrtf> > > The same is also true for __builtin_fma and __builtin_fmaf. > --- > sysdeps/arc/fpu/math-use-builtins-fma.h | 14 -- > sysdeps/arc/fpu/math-use-builtins-sqrt.h | 14 -- > 2 files changed, 24 insertions(+), 4 deletions(-) > > diff --git a/sysdeps/arc/fpu/math-use-builtins-fma.h > b/sysdeps/arc/fpu/math-use-builtins-fma.h > index eede75aa41be..082badf48201 100644 > --- a/sysdeps/arc/fpu/math-use-builtins-fma.h > +++ b/sysdeps/arc/fpu/math-use-builtins-fma.h > @@ -1,4 +1,14 @@ > -#define USE_FMA_BUILTIN 1 > -#define USE_FMAF_BUILTIN 1 > +#if defined __ARC_FPU_DP_DIV__ > +# define USE_SQRT_BUILTIN 1 > +#else > +# define USE_SQRT_BUILTIN 0 > +#endif > + > +#if defined __ARC_FPU_SP_DIV__ > +# define USE_SQRTF_BUILTIN 1 > +#else > +# define USE_SQRTF_BUILTIN 0 > +#endif > + > #define USE_FMAL_BUILTIN 0 > #define USE_FMAF128_BUILTIN 0 This is wrong, sqrt use macro do not belong for the fma switch file. > diff --git a/sysdeps/arc/fpu/math-use-builtins-sqrt.h > b/sysdeps/arc/fpu/math-use-builtins-sqrt.h > index e94c915ba66a..a449bc609295 100644 > --- a/sysdeps/arc/fpu/math-use-builtins-sqrt.h > +++ b/sysdeps/arc/fpu/math-use-builtins-sqrt.h > @@ -1,4 +1,14 @@ > -#define USE_SQRT_BUILTIN 1 > -#define USE_SQRTF_BUILTIN 1 > +#if defined __ARC_FPU_DP_DIV__ > +# define USE_SQRT_BUILTIN 1 > +#else > +# define USE_SQRT_BUILTIN 0 > +#endif > + > +#if defined __ARC_FPU_SP_DIV__ > +# define USE_SQRTF_BUILTIN 1 > +#else > +# define USE_SQRTF_BUILTIN 0 > +#endif > + > #define USE_SQRTL_BUILTIN 0 > #define USE_SQRTF128_BUILTIN 0 This is ok. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 00/51] cpuidle,rcu: Clean up the mess
On Thu, Jan 12, 2023 at 08:43:14PM +0100, Peter Zijlstra wrote: > Hi All! Hi Peter, > The (hopefully) final respin of cpuidle vs rcu cleanup patches. Barring any > objections I'll be queueing these patches in tip/sched/core in the next few > days. I'm sorry to have to bear some bad news on that front. :( I just had a go at testing this on a Juno dev board, using your queue.git sched/idle branch and defconfig + CONFIG_PROVE_LOCKING=y + CONFIG_DEBUG_LOCKDEP=y + CONFIG_DEBUG_ATOMIC_SLEEP=y. With that I consistently see RCU at boot time (log below). | = | WARNING: suspicious RCU usage | 6.2.0-rc3-00051-gced9b6eecb31 #1 Not tainted | - | include/trace/events/ipi.h:19 suspicious rcu_dereference_check() usage! | | other info that might help us debug this: | | | rcu_scheduler_active = 2, debug_locks = 1 | RCU used illegally from extended quiescent state! | no locks held by swapper/0/0. | | stack backtrace: | CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.2.0-rc3-00051-gced9b6eecb31 #1 | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II May 16 2021 | Call trace: | dump_backtrace.part.0+0xe4/0xf0 | show_stack+0x18/0x30 | dump_stack_lvl+0x98/0xd4 | dump_stack+0x18/0x34 | lockdep_rcu_suspicious+0xf8/0x10c | trace_ipi_raise+0x1a8/0x1b0 | arch_irq_work_raise+0x4c/0x70 | __irq_work_queue_local+0x48/0x80 | irq_work_queue+0x50/0x80 | __wake_up_klogd.part.0+0x98/0xe0 | defer_console_output+0x20/0x30 | vprintk+0x98/0xf0 | _printk+0x5c/0x84 | lockdep_rcu_suspicious+0x34/0x10c | trace_lock_acquire+0x174/0x180 | lock_acquire+0x3c/0x8c | _raw_spin_lock_irqsave+0x70/0x150 | down_trylock+0x18/0x50 | __down_trylock_console_sem+0x3c/0xd0 | console_trylock+0x28/0x90 | vprintk_emit+0x11c/0x354 | vprintk_default+0x38/0x4c | vprintk+0xd4/0xf0 | _printk+0x5c/0x84 | lockdep_rcu_suspicious+0x34/0x10c | printk_sprint+0x238/0x240 | vprintk_store+0x32c/0x4b0 | vprintk_emit+0x104/0x354 | vprintk_default+0x38/0x4c | vprintk+0xd4/0xf0 | _printk+0x5c/0x84 | lockdep_rcu_suspicious+0x34/0x10c | trace_irq_disable+0x1ac/0x1b0 | trace_hardirqs_off+0xe8/0x110 | cpu_suspend+0x4c/0xfc | psci_cpu_suspend_enter+0x58/0x6c | psci_enter_idle_state+0x70/0x170 | cpuidle_enter_state+0xc4/0x464 | cpuidle_enter+0x38/0x50 | do_idle+0x230/0x2c0 | cpu_startup_entry+0x24/0x30 | rest_init+0x110/0x190 | arch_post_acpi_subsys_init+0x0/0x18 | start_kernel+0x6f8/0x738 | __primary_switched+0xbc/0xc4 IIUC what's happenign here is the PSCI cpuidle driver has entered idle and RCU is no longer watching when arm64's cpu_suspend() manipulates DAIF. Our local_daif_*() helpers poke lockdep and tracing, hence the call to trace_hardirqs_off() and the RCU usage. I think we need RCU to be watching all the way down to cpu_suspend(), and it's cpu_suspend() that should actually enter/exit idle context. That and we need to make cpu_suspend() and the low-level PSCI invocation noinstr. I'm not sure whether 32-bit will have a similar issue or not. I'm surprised no-one else who has tested has seen this; I suspect people haven't enabled lockdep and friends. :/ Thanks, Mark. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 35/51] trace,hardirq: No moar _rcuidle() tracing
Hi Peter,
On Thu, 12 Jan 2023 20:43:49 +0100
Peter Zijlstra wrote:
> Robot reported that trace_hardirqs_{on,off}() tickle the forbidden
> _rcuidle() tracepoint through local_irq_{en,dis}able().
>
> For 'sane' configs, these calls will only happen with RCU enabled and
> as such can use the regular tracepoint. This also means it's possible
> to trace them from NMI context again.
>
> Signed-off-by: Peter Zijlstra (Intel)
The code looks good to me. I just have a question about comment.
> ---
> kernel/trace/trace_preemptirq.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> --- a/kernel/trace/trace_preemptirq.c
> +++ b/kernel/trace/trace_preemptirq.c
> @@ -20,6 +20,15 @@
> static DEFINE_PER_CPU(int, tracing_irq_cpu);
>
> /*
> + * ...
Is this intended? Wouldn't you leave any comment here?
Thank you,
> + */
> +#ifdef CONFIG_ARCH_WANTS_NO_INSTR
> +#define trace(point) trace_##point
> +#else
> +#define trace(point) if (!in_nmi()) trace_##point##_rcuidle
> +#endif
> +
> +/*
> * Like trace_hardirqs_on() but without the lockdep invocation. This is
> * used in the low level entry code where the ordering vs. RCU is important
> * and lockdep uses a staged approach which splits the lockdep hardirq
> @@ -28,8 +37,7 @@ static DEFINE_PER_CPU(int, tracing_irq_c
> void trace_hardirqs_on_prepare(void)
> {
> if (this_cpu_read(tracing_irq_cpu)) {
> - if (!in_nmi())
> - trace_irq_enable(CALLER_ADDR0, CALLER_ADDR1);
> + trace(irq_enable)(CALLER_ADDR0, CALLER_ADDR1);
> tracer_hardirqs_on(CALLER_ADDR0, CALLER_ADDR1);
> this_cpu_write(tracing_irq_cpu, 0);
> }
> @@ -40,8 +48,7 @@ NOKPROBE_SYMBOL(trace_hardirqs_on_prepar
> void trace_hardirqs_on(void)
> {
> if (this_cpu_read(tracing_irq_cpu)) {
> - if (!in_nmi())
> - trace_irq_enable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
> + trace(irq_enable)(CALLER_ADDR0, CALLER_ADDR1);
> tracer_hardirqs_on(CALLER_ADDR0, CALLER_ADDR1);
> this_cpu_write(tracing_irq_cpu, 0);
> }
> @@ -63,8 +70,7 @@ void trace_hardirqs_off_finish(void)
> if (!this_cpu_read(tracing_irq_cpu)) {
> this_cpu_write(tracing_irq_cpu, 1);
> tracer_hardirqs_off(CALLER_ADDR0, CALLER_ADDR1);
> - if (!in_nmi())
> - trace_irq_disable(CALLER_ADDR0, CALLER_ADDR1);
> + trace(irq_disable)(CALLER_ADDR0, CALLER_ADDR1);
> }
>
> }
> @@ -78,8 +84,7 @@ void trace_hardirqs_off(void)
> if (!this_cpu_read(tracing_irq_cpu)) {
> this_cpu_write(tracing_irq_cpu, 1);
> tracer_hardirqs_off(CALLER_ADDR0, CALLER_ADDR1);
> - if (!in_nmi())
> - trace_irq_disable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
> + trace(irq_disable)(CALLER_ADDR0, CALLER_ADDR1);
> }
> }
> EXPORT_SYMBOL(trace_hardirqs_off);
>
>
--
Masami Hiramatsu (Google)
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
