[PATCH v3 00/14] ARM: enable IRQ stacks and vmap'ed stacks for UP
Marc Zyngier
maz at kernel.org
Fri Dec 3 04:53:56 PST 2021
On Fri, 03 Dec 2021 10:08:49 +0000,
Ard Biesheuvel <ardb at kernel.org> wrote:
>
> First, 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.
FWIW, I've given this a go on a Netwinder (of the Footbridge family),
and nothing caught fire. I'm not using modules though.
Tested-by: Marc Zyngier <maz at kernel.org>
M.
--
Without deviation from the norm, progress is not possible.
More information about the linux-arm-kernel
mailing list