[PATCH v2 00/12] ARM: enable IRQ stacks and vmap'ed stacks for UP

Arnd Bergmann arnd at arndb.de
Tue Nov 30 06:08:09 PST 2021


On Tue, Nov 30, 2021 at 1:58 PM Ard Biesheuvel <ardb at kernel.org> wrote:
>
> Enable the use of the TLS register to hold the 'current' pointer for all
> configurations that can support it, including non-SMP ones that target
> v6k or later CPUs, and multi-platform SMP ones that also support v6
> based UP systems.
>
> The remaining configurations are all strictly UP, which means we can
> switch to a global variable to hold the current pointer. By doing this,
> we can enable THREAD_INFO_IN_TASK, which moves thread info off the
> stack, protecting it from overflows. It also permits us to enable IRQ
> stacks and vmap'ed stacks for UP configurations as well.
>
> Supporting v6 cores without SMP extensions in SMP configurations (e.g.,
> omap2plus_defconfig or imx_v6_v7_defconfig) makes this a bit tricky, and
> this is a feature we may consider dropping entirely in the future. But
> for the time being, we can support this mode as well.
>
> The accesses to the global variable holding 'current' are constructed in
> a way that ensures that no literal pool accesses (and associated D-cache
> misses) are needed unless the access is from a module and module PLTs
> are enabled. This means that accessing 'current' is just as costly as
> before, as it used to require some arithmetic involving the stack
> pointer and a load from the thread_info::task field.
>
> However, accessing thread_info itself now also involves a load, although
> it should be noted that all thread_info and current accesses now go via
> the same variable, which is therefore expected to be hot in the caches
> at all times.

Most of your assembler changes are beyond my understanding of that
code, but everything that I do understand moves the code in the right
direction, this looks really good overall.

I'll add this to my randconfig compile test setup to see if that finds any
corner cases you may have missed.

        Arnd



More information about the linux-arm-kernel mailing list