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 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
