am335x: 5.18.x: system stalling
Yegor Yefremov
yegorslists at googlemail.com
Sat May 28 06:01:05 PDT 2022
On Sat, May 28, 2022 at 11:07 AM Ard Biesheuvel <ardb at kernel.org> wrote:
>
> On Sat, 28 May 2022 at 10:29, Yegor Yefremov <yegorslists at googlemail.com> wrote:
> >
> > On Sat, May 28, 2022 at 9:53 AM Arnd Bergmann <arnd at arndb.de> wrote:
> > >
> > > On Sat, May 28, 2022 at 7:48 AM Yegor Yefremov
> > > <yegorslists at googlemail.com> wrote:
> > > >
> > > > On Fri, May 27, 2022 at 4:13 PM Arnd Bergmann <arnd at arndb.de> wrote:
> > > > >
> > > > > 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 have tried this patch and the system still stalls.
> > >
> > > Ok, thanks for testing. To clarify: did you test with both the get_current() and
> > > __my_cpu_offset() changes applied, or just the get_current() one?
> >
> > I have tested only the get_current() one. Should I also test
> > __my_cpu_offset() separately and combined?
> >
>
> That would be helpful, yes.
SYNC include/config/auto.conf.cmd
CC kernel/bounds.s
CALL scripts/atomic/check-atomics.sh
In file included from ./include/linux/irqflags.h:17,
from ./arch/arm/include/asm/bitops.h:28,
from ./include/linux/bitops.h:33,
from ./include/linux/log2.h:12,
from kernel/bounds.c:13:
./arch/arm/include/asm/percpu.h: In function ‘__my_cpu_offset’:
./arch/arm/include/asm/percpu.h:32:9: error: ‘__per_cpu_offset’
undeclared (first use in this function); did you mean
‘__my_cpu_offset’?
32 | return __per_cpu_offset[0];
| ^~~~~~~~~~~~~~~~
| __my_cpu_offset
./arch/arm/include/asm/percpu.h:32:9: note: each undeclared identifier
is reported only once for each function it appears in
Yegor
More information about the linux-arm-kernel
mailing list