archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <>
To: dann frazier <>
Cc: Catalin Marinas <>,
	Will Deacon <>,
	Suzuki K Poulose <>,
Subject: Re: [PATCH] arm64: Generate cpucaps.h
Date: Tue, 21 Sep 2021 19:35:52 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <YUofi2vKczeqCpr2@xps13.dannf>

[-- Attachment #1.1: Type: text/plain, Size: 1683 bytes --]

On Tue, Sep 21, 2021 at 12:08:11PM -0600, dann frazier wrote:
> On Wed, Apr 28, 2021 at 01:12:31PM +0100, Mark Brown wrote:

> > This will result in a renumbering and reordering of the existing constants,
> > since they are all internal only the values should not be important. The
> > reordering will impact the order in which some steps in enumeration handle
> > features but the algorithm is not intended to depend on this and I haven't
> > seen any issues when testing.

> Unfortunately I believe I've hit a regression[*] due to such an
> ordering dependency. UNMAP_KERNEL_AT_EL0 currently needs to be
> processed after WORKAROUND_CAVIUM_27456. ThunderX systems are
> incompatible with KPTI, so unmap_kernel_at_el0() bails if
> WORKAROUND_CAVIUM_27456 is set. Because of the sorting,
> WORKAROUND_CAVIUM_27456 will not yet have been considered when
> unmap_kernel_at_el0() checks for it, so the kernel tries to
> run w/ KPTI - and quickly falls over.

> I've verified that reordering cpucaps to move WORKAROUND_CAVIUM_27456
> just above UNMAP_KERNEL_AT_EL0 restores the old behavior. I'm not sure
> of the right way to address this - perhaps unmap_kernel_at_el0() could
> check cavium_erratum_27456_cpus[] directly instead of keying on the

Ugh, right.  Another option would be to do something like rename to
CAVIUM_WORKAROUND_27456 which would be inconsistent naming and but would
sort things in a way that gets the checks to run in the order we're
relying on but either works for me.  Neither is great.

It'd be really good to get more coverage of the enterprise systems in
KernelCI or similar so we can catch issues like this more easily.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

linux-arm-kernel mailing list

  reply	other threads:[~2021-09-21 18:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-28 12:12 [PATCH] arm64: Generate cpucaps.h Mark Brown
2021-04-29 12:32 ` Catalin Marinas
2021-05-04 11:43 ` Mark Rutland
2021-05-10 12:55 ` Catalin Marinas
2021-05-13  5:05 ` Anshuman Khandual
2021-05-13 11:51   ` Mark Rutland
2021-05-13 12:45   ` Mark Brown
2021-05-13 11:30 ` Geert Uytterhoeven
2021-05-13 13:03   ` Mark Brown
2021-09-21 18:08 ` dann frazier
2021-09-21 18:35   ` Mark Brown [this message]
2021-09-21 21:09     ` Suzuki K Poulose
2021-09-22 13:45       ` dann frazier

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).