am335x: 5.18.x: system stalling

[Arnd Bergmann]

On Fri, May 27, 2022 at 3:12 PM Ard Biesheuvel <ardb at kernel.org> wrote:
> On Fri, 27 May 2022 at 14:54, Arnd Bergmann <arnd at arndb.de> wrote:
> > On Fri, May 27, 2022 at 11:50 AM Yegor Yefremov <yegorslists at googlemail.com> wrote:
>
> Not just per-cpu data: there is also the 'current' global variable
> which gets used now instead of the user thread ID register, and this
> is also different between modules and the core kernel (unless
> CONFIG_ARM_MODULE_PLTS is disabled)

Right, so if the percpu hack doesn't address it, this one might:

diff --git a/arch/arm/include/asm/current.h b/arch/arm/include/asm/current.h
index 1e1178bf176d..306d1a4cae40 100644
--- a/arch/arm/include/asm/current.h
+++ b/arch/arm/include/asm/current.h
@@ -18,6 +18,8 @@ static __always_inline __attribute_const__ struct
task_struct *get_current(void)
 {
        struct task_struct *cur;

+       return __current;
+
 #if __has_builtin(__builtin_thread_pointer) && \
     defined(CONFIG_CURRENT_POINTER_IN_TPIDRURO) && \
     !(defined(CONFIG_THUMB2_KERNEL) && \

> I looked at the fdti-sio and slcan modules, and didn't find any
> references to per-CPU offsets when building them using the provided
> .config. I did find some references to __current, but these seem to be
> ignored (they are only emitted to satisfy the "m" inline asm
> constraint in get_domain(), but the parameter is never actually used
> in the assembler code)

I see some __current references in the musb driver that come from
tracepoints as well (in omap2plus_defconfig), but these also shouldn't be
active.

        Arnd