On 21/09/2021 19:35, Mark Brown wrote:

On Tue, Sep 21, 2021 at 12:08:11PM -0600, dann frazier wrote:

quoted

On Wed, Apr 28, 2021 at 01:12:31PM +0100, Mark Brown wrote:

quoted

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.

quoted

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.

quoted

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?

Given that these capabilities are LOCAL_CPU scope, and the systems in
question never have heterogeneous CPUs, you could replace

  cpus_have_const_cap() =>  this_cpu_has_cap()

in unmap_kernel_at_el0().

If they were heterogeneous, we would fail anyway, no matter what the
order was.

Suzuki

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