[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18c9318c-d122-b534-b526-318935d9e2cc@linaro.org>
Date: Fri, 11 Oct 2019 11:31:02 -0400
From: Richard Henderson <richard.henderson@...aro.org>
To: Dave Martin <Dave.Martin@....com>, linux-kernel@...r.kernel.org
Cc: Andrew Jones <drjones@...hat.com>, Arnd Bergmann <arnd@...db.de>,
Catalin Marinas <catalin.marinas@....com>,
Eugene Syromiatnikov <esyr@...hat.com>,
Florian Weimer <fweimer@...hat.com>,
"H.J. Lu" <hjl.tools@...il.com>, Jann Horn <jannh@...gle.com>,
Kees Cook <keescook@...omium.org>,
Kristina Martšenko <kristina.martsenko@....com>,
Mark Brown <broonie@...nel.org>,
Paul Elliott <paul.elliott@....com>,
Peter Zijlstra <peterz@...radead.org>,
Sudakshina Das <sudi.das@....com>,
Szabolcs Nagy <szabolcs.nagy@....com>,
Thomas Gleixner <tglx@...utronix.de>,
Will Deacon <will.deacon@....com>,
Yu-cheng Yu <yu-cheng.yu@...el.com>,
Amit Kachhap <amit.kachhap@....com>,
Vincenzo Frascino <vincenzo.frascino@....com>,
linux-arch@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 08/12] arm64: BTI: Decode BYTPE bits when printing
PSTATE
On 10/10/19 2:44 PM, Dave Martin wrote:
> #define PSR_IL_BIT (1 << 20)
> -#define PSR_BTYPE_CALL (2 << PSR_BTYPE_SHIFT)
> +
> +/* Convenience names for the values of PSTATE.BTYPE */
> +#define PSR_BTYPE_NONE (0b00 << PSR_BTYPE_SHIFT)
> +#define PSR_BTYPE_JC (0b01 << PSR_BTYPE_SHIFT)
> +#define PSR_BTYPE_C (0b10 << PSR_BTYPE_SHIFT)
> +#define PSR_BTYPE_J (0b11 << PSR_BTYPE_SHIFT)
It'd be nice to sort this patch earlier, so that ...
> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> index 4a3bd32..452ac5b 100644
> --- a/arch/arm64/kernel/signal.c
> +++ b/arch/arm64/kernel/signal.c
> @@ -732,7 +732,7 @@ static void setup_return(struct pt_regs *regs, struct k_sigaction *ka,
>
> if (system_supports_bti()) {
> regs->pstate &= ~PSR_BTYPE_MASK;
> - regs->pstate |= PSR_BTYPE_CALL;
> + regs->pstate |= PSR_BTYPE_C;
> }
>
> if (ka->sa.sa_flags & SA_RESTORER)
... setup_return does not need to be adjusted a second time.
I don't see any other conflicts vs patch 5.
r~
Powered by blists - more mailing lists