All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 Keith Packard <keithpac@amazon.com>,
	Russell King <linux@armlinux.org.uk>,
	 Kees Cook <keescook@chromium.org>, Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH v5 4/5] ARM: smp: Store current pointer in TPIDRURO register if available
Date: Tue, 21 Sep 2021 17:59:50 +0200	[thread overview]
Message-ID: <CAMj1kXHNthsN6hBOghPGP=QU9sYGuROL3OutKqOtM7s5XvqUEw@mail.gmail.com> (raw)
In-Reply-To: <CACRpkdbhz20uNX5S+4r0cGCvBm4U4Xxjie4KnyvUd2cUPc=8hQ@mail.gmail.com>

On Tue, 21 Sept 2021 at 17:46, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Sat, Sep 18, 2021 at 10:44 AM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> > Now that the user space TLS register is assigned on every return to user
> > space, we can use it to keep the 'current' pointer while running in the
> > kernel. This removes the need to access it via thread_info, which is
> > located at the base of the stack, but will be moved out of there in a
> > subsequent patch.
> >
> > Use the __builtin_thread_pointer() helper when available - this will
> > help GCC understand that reloading the value within the same function is
> > not necessary, even when using the per-task stack protector (which also
> > generates accesses via the TLS register). For example, the generated
> > code below loads TPIDRURO only once, and uses it to access both the
> > stack canary and the preempt_count fields.
> >
> > <do_one_initcall>:
> >        e92d 41f0       stmdb   sp!, {r4, r5, r6, r7, r8, lr}
> >        ee1d 4f70       mrc     15, 0, r4, cr13, cr0, {3}
> >        4606            mov     r6, r0
> >        b094            sub     sp, #80 ; 0x50
> >        f8d4 34e8       ldr.w   r3, [r4, #1256] ; 0x4e8  <- stack canary
> >        9313            str     r3, [sp, #76]   ; 0x4c
> >        f8d4 8004       ldr.w   r8, [r4, #4]             <- preempt count
> >
> > Co-developed-by: Keith Packard <keithpac@amazon.com>
> > Signed-off-by: Keith Packard <keithpac@amazon.com>
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>
> I like the __builtin trick, I had to look up the patch that adds
> this to GCC to understand what is going on.

Yes. Note that patch #1 adds a call to gen_load_tp_hard() to the GCC
plugin, which is what backs __builtin_thread_pointer() when -mtp=cp15
is used. This is what permits GCC to infer that it can reuse the
value. (Inline asm is completely opaque to the compiler so it lacks
the implicit connotation that the thread pointer cannot change values
halfway through a function)

> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>

Thanks!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-09-21 16:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-18  8:44 [PATCH v5 0/5] ARM: support THREAD_INFO_IN_TASK Ard Biesheuvel
2021-09-18  8:44 ` [PATCH v5 1/5] gcc-plugins: arm-ssp: Prepare for THREAD_INFO_IN_TASK support Ard Biesheuvel
2021-09-18 23:20   ` Linus Walleij
2021-09-18  8:44 ` [PATCH v5 2/5] ARM: smp: Pass task to secondary_start_kernel Ard Biesheuvel
2021-09-18 23:20   ` Linus Walleij
2021-09-18  8:44 ` [PATCH v5 3/5] ARM: smp: Free up the TLS register while running in the kernel Ard Biesheuvel
2021-09-21 15:20   ` Linus Walleij
2021-09-18  8:44 ` [PATCH v5 4/5] ARM: smp: Store current pointer in TPIDRURO register if available Ard Biesheuvel
2021-09-21 15:45   ` Linus Walleij
2021-09-21 15:59     ` Ard Biesheuvel [this message]
2021-09-18  8:44 ` [PATCH v5 5/5] ARM: smp: Enable THREAD_INFO_IN_TASK Ard Biesheuvel
2021-09-19 13:38   ` Amit Kachhap
2021-09-19 16:22     ` Ard Biesheuvel
2021-09-21 16:20   ` Linus Walleij
2021-09-19 13:44 ` [PATCH v5 0/5] ARM: support THREAD_INFO_IN_TASK Amit Kachhap
2021-09-19 16:23   ` Ard Biesheuvel

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='CAMj1kXHNthsN6hBOghPGP=QU9sYGuROL3OutKqOtM7s5XvqUEw@mail.gmail.com' \
    --to=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 \
    /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.