On Fri, May 27, 2022 at 4:13 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> On Fri, May 27, 2022 at 3:12 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> > On Fri, 27 May 2022 at 14:54, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > > On Fri, May 27, 2022 at 11:50 AM Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx> 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 have tried this patch and the system still stalls.
Yegor
> > 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
