From 533b092be41428400e30d6a38a5412011bc29d77 Mon Sep 17 00:00:00 2001 From: Bruce Ashfield Date: Mon, 1 Jan 2024 23:31:05 -0500 Subject: [PATCH] linux-yocto/6.6: fix AB-INT: QEMU kernel panic: No irq handler for vector Integrating the following commit(s) to linux-yocto/6.6: 1/2 [ Author: Thomas Gleixner Email: tglx@linutronix.de Subject: x86/alternatives: Sync core before enabling interrupts Date: Thu, 7 Dec 2023 20:49:24 +0100 text_poke_early() does: local_irq_save(flags); memcpy(addr, opcode, len); local_irq_restore(flags); sync_core(); That's not really correct because the synchronization should happen before interrupts are reenabled to ensure that a pending interrupt observes the complete update of the opcodes. It's not entirely clear whether the interrupt entry provides enough serialization already, but moving the sync_core() invocation into interrupt disabled region does no harm and is obviously correct. Signed-off-by: Thomas Gleixner Signed-off-by: Bruce Ashfield ] 2/2 [ Author: Thomas Gleixner Email: tglx@linutronix.de Subject: x86/alternatives: Disable interrupts and sync when optimizing NOPs in place Date: Thu, 7 Dec 2023 20:49:26 +0100 apply_alternatives() treats alternatives with the ALT_FLAG_NOT flag set special as it optimizes the existing NOPs in place. Unfortunately this happens with interrupts enabled and does not provide any form of core synchronization. So an interrupt hitting in the middle of the update and using the affected code path will observe a half updated NOP and crash and burn. The following 3 NOP sequence was observed to expose this crash halfways reliably under QEMU 32bit: 0x90 0x90 0x90 which is replaced by the optimized 3 byte NOP: 0x8d 0x76 0x00 So an interrupt can observe: 1) 0x90 0x90 0x90 nop nop nop 2) 0x8d 0x90 0x90 undefined 3) 0x8d 0x76 0x90 lea -0x70(%esi),%esi 4) 0x8d 0x76 0x00 lea 0x0(%esi),%esi Where only #1 and #4 are true NOPs. The same problem exists for 64bit obviously. Disable interrupts around this NOP optimization and invoke sync_core() before reenabling them. Fixes: 270a69c4485d ("x86/alternative: Support relocations in alternatives") Reported-by: Paul Gortmaker Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Signed-off-by: Bruce Ashfield ] Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie --- .../linux/linux-yocto-rt_6.6.bb | 2 +- .../linux/linux-yocto-tiny_6.6.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_6.6.bb | 22 +++++++++---------- 3 files changed, 13 insertions(+), 13 deletions(-) diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_6.6.bb b/meta/recipes-kernel/linux/linux-yocto-rt_6.6.bb index 0c0ce6afea7e..9a9d1ab33a09 100644 --- a/meta/recipes-kernel/linux/linux-yocto-rt_6.6.bb +++ b/meta/recipes-kernel/linux/linux-yocto-rt_6.6.bb @@ -14,7 +14,7 @@ python () { raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it") } -SRCREV_machine ?= "bce0cb6bbe24682d839c3e212270e3744e32aabe" +SRCREV_machine ?= "3364e561d527a5dcca1803dcf5a7e2a7aa3a398e" SRCREV_meta ?= "8ab17895c185426442d80a60829619270f9ac51d" SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine;protocol=https \ diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_6.6.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_6.6.bb index edb8001069bb..547b5ee92215 100644 --- a/meta/recipes-kernel/linux/linux-yocto-tiny_6.6.bb +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_6.6.bb @@ -17,7 +17,7 @@ DEPENDS += "openssl-native util-linux-native" KMETA = "kernel-meta" KCONF_BSP_AUDIT_LEVEL = "2" -SRCREV_machine ?= "09118b4441395fadf233eec03e2b68e7d6d63cdd" +SRCREV_machine ?= "58e5c91d6701f62e0f72b1f10c2e9f14b2eb4480" SRCREV_meta ?= "8ab17895c185426442d80a60829619270f9ac51d" PV = "${LINUX_VERSION}+git" diff --git a/meta/recipes-kernel/linux/linux-yocto_6.6.bb b/meta/recipes-kernel/linux/linux-yocto_6.6.bb index 4fa6c505f53e..57a394d171fc 100644 --- a/meta/recipes-kernel/linux/linux-yocto_6.6.bb +++ b/meta/recipes-kernel/linux/linux-yocto_6.6.bb @@ -18,17 +18,17 @@ KBRANCH:qemux86-64 ?= "v6.6/standard/base" KBRANCH:qemuloongarch64 ?= "v6.6/standard/base" KBRANCH:qemumips64 ?= "v6.6/standard/mti-malta64" -SRCREV_machine:qemuarm ?= "8a23d09163eedc42ed63f2741ae2fa7d8aa926aa" -SRCREV_machine:qemuarm64 ?= "09118b4441395fadf233eec03e2b68e7d6d63cdd" -SRCREV_machine:qemuloongarch64 ?= "09118b4441395fadf233eec03e2b68e7d6d63cdd" -SRCREV_machine:qemumips ?= "a0a00df5c1cd3cdd346f410f71998a120e284f78" -SRCREV_machine:qemuppc ?= "09118b4441395fadf233eec03e2b68e7d6d63cdd" -SRCREV_machine:qemuriscv64 ?= "09118b4441395fadf233eec03e2b68e7d6d63cdd" -SRCREV_machine:qemuriscv32 ?= "09118b4441395fadf233eec03e2b68e7d6d63cdd" -SRCREV_machine:qemux86 ?= "09118b4441395fadf233eec03e2b68e7d6d63cdd" -SRCREV_machine:qemux86-64 ?= "09118b4441395fadf233eec03e2b68e7d6d63cdd" -SRCREV_machine:qemumips64 ?= "971214747a173452ae3ab4c6dcf1d91451b6e9be" -SRCREV_machine ?= "09118b4441395fadf233eec03e2b68e7d6d63cdd" +SRCREV_machine:qemuarm ?= "ff8331e10427c145659bf6a5f87b9109011159cf" +SRCREV_machine:qemuarm64 ?= "58e5c91d6701f62e0f72b1f10c2e9f14b2eb4480" +SRCREV_machine:qemuloongarch64 ?= "58e5c91d6701f62e0f72b1f10c2e9f14b2eb4480" +SRCREV_machine:qemumips ?= "afa3730deded0bc56f1470b59f65d86f20dfb256" +SRCREV_machine:qemuppc ?= "58e5c91d6701f62e0f72b1f10c2e9f14b2eb4480" +SRCREV_machine:qemuriscv64 ?= "58e5c91d6701f62e0f72b1f10c2e9f14b2eb4480" +SRCREV_machine:qemuriscv32 ?= "58e5c91d6701f62e0f72b1f10c2e9f14b2eb4480" +SRCREV_machine:qemux86 ?= "58e5c91d6701f62e0f72b1f10c2e9f14b2eb4480" +SRCREV_machine:qemux86-64 ?= "58e5c91d6701f62e0f72b1f10c2e9f14b2eb4480" +SRCREV_machine:qemumips64 ?= "a93ff794461d9ba7ec5b02d482b60d9ca582e97f" +SRCREV_machine ?= "58e5c91d6701f62e0f72b1f10c2e9f14b2eb4480" SRCREV_meta ?= "8ab17895c185426442d80a60829619270f9ac51d" # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and you'll