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:

quoted

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
ARM64_WORKAROUND_CAVIUM_27456 cap?

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.