[PATCH v4 0/5] ARM: support THREAD_INFO_IN_TASK

Ard Biesheuvel ardb at kernel.org
Tue Sep 14 10:10:49 PDT 2021


On Tue, 14 Sept 2021 at 15:07, Arnd Bergmann <arnd at arndb.de> wrote:
>
> On Tue, Sep 14, 2021 at 11:50 AM Ard Biesheuvel <ardb at kernel.org> wrote:
> > On Tue, 14 Sept 2021 at 11:44, Arnd Bergmann <arnd at arndb.de> wrote:
> >
> > > I haven't looked in detail, but it all looks great to me so far.
> > >
> > > On a related note, this reminds me of the CONFIG_IRQSTACK series
> > > that was posted last year[1] and probably attempted before that.
> > > I'd have to get back to understanding all the details of that discussion,
> > > but I have some hope that adding irqstacks would become much
> > > easier after your series. Any thoughts on that?
> >
> > Yes, not having to rely on the stack pointer for thread_info/current
> > seems to make this a lot easier. And eith mentioned that he is also
> > interested in vmap'ed stacks for ARM, so I have a suspicion that we
> > will end up picking up some IRQ stack changes in the process as well.
>
> Ah, perfect! Adding vmap stack also solves ones of the issues for
> the 4G:4G split: since vmalloc/vmap space is always mapped in
> kernel mode, copy_{from,to}_user() can then just use memcpy()
> with TTBR0 switched to used memory if the kernel buffer is on the
> stack, or use an intermediate buffer on the stack if it's not.
>

Yeah I was wondering how that would interact with the 4/4 split work.

In any case, I had a stab at the basic IRQ stacks support here:
https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-irq-stacks

Haven't looked at the backtrace/unwind part yet.



More information about the linux-arm-kernel mailing list