On 24/05/2022 16:21, Ard Biesheuvel wrote:
On Tue, 24 May 2022 at 16:50, Jon Hunter <jonathanh@xxxxxxxxxx> wrote:
Hi Ard,
On 28/03/2022 14:47, Ard Biesheuvel wrote:
The Spectre-BHB mitigations were inadvertently left disabled for
Cortex-A15, due to the fact that cpu_v7_bugs_init() is not called in
that case. So fix that.
Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx>
---
arch/arm/mm/proc-v7-bugs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mm/proc-v7-bugs.c b/arch/arm/mm/proc-v7-bugs.c
index 06dbfb968182..fb9f3eb6bf48 100644
--- a/arch/arm/mm/proc-v7-bugs.c
+++ b/arch/arm/mm/proc-v7-bugs.c
@@ -288,6 +288,7 @@ void cpu_v7_ca15_ibe(void)
{
if (check_spectre_auxcr(this_cpu_ptr(&spectre_warned), BIT(0)))
cpu_v7_spectre_v2_init();
+ cpu_v7_spectre_bhb_init();
}
void cpu_v7_bugs_init(void)
Since this patch has been merged, I am seeing a ton of messages when
booting Linux on tegra124-jetson-tk1 ...
Thanks for the report. The good news is that the Spectre BHB
protection is finally taking effect on your system.
[ 1233.327547] CPU0: Spectre BHB: using loop workaround
[ 1233.327795] CPU1: Spectre BHB: using loop workaround
[ 1233.328270] CPU1: Spectre BHB: using loop workaround
[ 1233.328700] CPU1: Spectre BHB: using loop workaround
[ 1233.355477] CPU2: Spectre BHB: using loop workaround
** 7 printk messages dropped **
[ 1233.366271] CPU0: Spectre BHB: using loop workaround
[ 1233.366580] CPU0: Spectre BHB: using loop workaround
[ 1233.366815] CPU1: Spectre BHB: using loop workaround
[ 1233.405475] CPU1: Spectre BHB: using loop workaround
[ 1233.405874] CPU0: Spectre BHB: using loop workaround
[ 1233.406041] CPU1: Spectre BHB: using loop workaround
** 1 printk messages dropped **
This is significantly increasing the boot time and causing failures if
the boot takes too long.
I see that Dmitry has posted a fix for one of these cases [0], but the
above also needs to be fixed.
Agreed.
Do we have any idea why this init hook is being called so often? Is
this expected on systems that do agressive suspend/resume for power
management, or is there another existing issue here that is just
coming to light due to the newly added printk() ?
So far I have not dug any further, but I do know it is not doing any
aggressive suspend/resume. From what Dmitry indicated he saw this during
CPU idle transitions and this platform would definitely by exercising
CPU idle.
Jon
--
nvpublic
