From: Marc Zyngier <maz@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, linux@armlinux.org.uk,
Nicolas Pitre <nico@fluxnic.net>, Arnd Bergmann <arnd@arndb.de>,
Kees Cook <keescook@chromium.org>,
Keith Packard <keithpac@amazon.com>,
Linus Walleij <linus.walleij@linaro.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Tony Lindgren <tony@atomide.com>,
Vladimir Murzin <vladimir.murzin@arm.com>,
Jesse Taube <mr.bossman075@gmail.com>
Subject: Re: [PATCH v3 00/14] ARM: enable IRQ stacks and vmap'ed stacks for UP
Date: Fri, 03 Dec 2021 12:53:56 +0000 [thread overview]
Message-ID: <874k7pn923.wl-maz@kernel.org> (raw)
In-Reply-To: <20211203100903.334206-1-ardb@kernel.org>
On Fri, 03 Dec 2021 10:08:49 +0000,
Ard Biesheuvel <ardb@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@kernel.org>
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-12-03 12:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-03 10:08 [PATCH v3 00/14] ARM: enable IRQ stacks and vmap'ed stacks for UP Ard Biesheuvel
2021-12-03 10:08 ` [PATCH v3 01/14] ARM: riscpc: use GENERIC_IRQ_MULTI_HANDLER Ard Biesheuvel
2021-12-03 10:08 ` [PATCH v3 02/14] ARM: footbridge: " Ard Biesheuvel
2021-12-03 10:08 ` [PATCH v3 03/14] ARM: iop32x: offset IRQ numbers by 1 Ard Biesheuvel
2021-12-03 10:08 ` [PATCH v3 04/14] ARM: iop32x: use GENERIC_IRQ_MULTI_HANDLER Ard Biesheuvel
2021-12-03 10:08 ` [PATCH v3 05/14] ARM: remove old-style irq entry Ard Biesheuvel
2021-12-03 10:08 ` [PATCH v3 06/14] irqchip: nvic: Use GENERIC_IRQ_MULTI_HANDLER Ard Biesheuvel
2021-12-03 10:08 ` [PATCH v3 07/14] ARM: entry: preserve thread_info pointer in switch_to Ard Biesheuvel
2021-12-03 10:08 ` [PATCH v3 08/14] ARM: module: implement support for PC-relative group relocations Ard Biesheuvel
2021-12-03 10:08 ` [PATCH v3 09/14] ARM: assembler: add optimized ldr/str macros to load variables from memory Ard Biesheuvel
2021-12-03 10:08 ` [PATCH v3 10/14] ARM: percpu: add SMP_ON_UP support Ard Biesheuvel
2021-12-03 10:09 ` [PATCH v3 11/14] ARM: use TLS register for 'current' on !SMP as well Ard Biesheuvel
2021-12-03 10:09 ` [PATCH v3 12/14] ARM: smp: defer TPIDRURO update for SMP v6 configurations too Ard Biesheuvel
2021-12-03 10:09 ` [PATCH v3 13/14] ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems Ard Biesheuvel
2021-12-03 10:09 ` [PATCH v3 14/14] ARM: v7m: enable support for IRQ stacks Ard Biesheuvel
2021-12-03 10:46 ` [PATCH v3 00/14] ARM: enable IRQ stacks and vmap'ed stacks for UP Vladimir Murzin
2021-12-03 12:53 ` Marc Zyngier [this message]
2021-12-05 0:38 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874k7pn923.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=keescook@chromium.org \
--cc=keithpac@amazon.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=mr.bossman075@gmail.com \
--cc=ndesaulniers@google.com \
--cc=nico@fluxnic.net \
--cc=tony@atomide.com \
--cc=vladimir.murzin@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.