On Fri, 25 Oct 2019 at 17:25, Sasha Levin sashal@kernel.org wrote:
On Thu, Oct 24, 2019 at 04:37:12PM +0200, Ard Biesheuvel wrote:
On Thu, 24 Oct 2019 at 16:34, Alexandru Elisei alexandru.elisei@arm.com wrote:
Hi,
On 10/24/19 1:48 PM, Ard Biesheuvel wrote:
From: Jeremy Linton jeremy.linton@arm.com
[ Upstream commit 8c1e3d2bb44cbb998cb28ff9a18f105fee7f1eb3 ]
Ensure we are always able to detect whether or not the CPU is affected by Spectre-v2, so that we can later advertise this to userspace.
Signed-off-by: Jeremy Linton jeremy.linton@arm.com Reviewed-by: Andre Przywara andre.przywara@arm.com Reviewed-by: Catalin Marinas catalin.marinas@arm.com Tested-by: Stefan Wahren stefan.wahren@i2se.com Signed-off-by: Will Deacon will.deacon@arm.com Signed-off-by: Ard Biesheuvel ard.biesheuvel@linaro.org
arch/arm64/kernel/cpu_errata.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c index bf6d8aa9b45a..647c533cfd90 100644 --- a/arch/arm64/kernel/cpu_errata.c +++ b/arch/arm64/kernel/cpu_errata.c @@ -76,7 +76,6 @@ cpu_enable_trap_ctr_access(const struct arm64_cpu_capabilities *__unused) config_sctlr_el1(SCTLR_EL1_UCT, 0); }
-#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR #include <asm/mmu_context.h> #include <asm/cacheflush.h>
@@ -217,11 +216,11 @@ static int detect_harden_bp_fw(void) ((midr & MIDR_CPU_MODEL_MASK) == MIDR_QCOM_FALKOR_V1)) cb = qcom_link_stack_sanitization;
install_bp_hardening_cb(cb, smccc_start, smccc_end);
if (IS_ENABLED(CONFIG_HARDEN_BRANCH_PREDICTOR))install_bp_hardening_cb(cb, smccc_start, smccc_end); return 1;} -#endif /* CONFIG_HARDEN_BRANCH_PREDICTOR */
DEFINE_PER_CPU_READ_MOSTLY(u64, arm64_ssbd_callback_required);
@@ -457,7 +456,6 @@ static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry, .type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM, \ CAP_MIDR_RANGE_LIST(midr_list)
-#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR /*
- List of CPUs that do not need any Spectre-v2 mitigation at all.
*/ @@ -489,6 +487,12 @@ check_branch_predictor(const struct arm64_cpu_capabilities *entry, int scope) if (!need_wa) return false;
if (!IS_ENABLED(CONFIG_HARDEN_BRANCH_PREDICTOR)) {pr_warn_once("spectrev2 mitigation disabled by kernel configuration\n");__hardenbp_enab = false;This breaks when building, because __hardenbp_enab is declared in the next patch:
$ make -j32 defconfig && make -j32
[..] arch/arm64/kernel/cpu_errata.c: In function ‘check_branch_predictor’: arch/arm64/kernel/cpu_errata.c:492:3: error: ‘__hardenbp_enab’ undeclared (first use in this function) __hardenbp_enab = false; ^~~~~~~~~~~~~~~ arch/arm64/kernel/cpu_errata.c:492:3: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [scripts/Makefile.build:326: arch/arm64/kernel/cpu_errata.o] Error 1 make[1]: *** Waiting for unfinished jobs....
Indeed, but as discussed, this matches the state of both mainline and v4.19, which carry these patches in the same [wrong] order as well.
Greg should confirm, but as I understand it, it is preferred to be bug-compatible with mainline rather than fixing problems when spotting them while doing the backport.
Is it just patch ordering? If so I'd rather fix it, there's no reason to carry this issue into the stable trees.
We reserve "bug compatibility" for functional issues that are not yet fixed upstream, it doesn't seem to be the case here.
The patches don't apply cleanly in the opposite order.