From: Greg Kroah-Hartman Date: Mon, 22 Mar 2021 09:55:43 +0000 (+0100) Subject: 5.4-stable patches X-Git-Tag: v4.4.263~16 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=37d34c14071dbed68c2cb670aac97e8c56d77008;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: efi-use-32-bit-alignment-for-efi_guid_t-literals.patch firmware-efi-fix-a-use-after-bug-in-efi_mem_reserve_persistent.patch genirq-disable-interrupts-for-force-threaded-handlers.patch x86-apic-of-fix-cpu-devicetree-node-lookups.patch --- diff --git a/queue-5.4/efi-use-32-bit-alignment-for-efi_guid_t-literals.patch b/queue-5.4/efi-use-32-bit-alignment-for-efi_guid_t-literals.patch new file mode 100644 index 00000000000..92ef7db68f6 --- /dev/null +++ b/queue-5.4/efi-use-32-bit-alignment-for-efi_guid_t-literals.patch @@ -0,0 +1,66 @@ +From fb98cc0b3af2ba4d87301dff2b381b12eee35d7d Mon Sep 17 00:00:00 2001 +From: Ard Biesheuvel +Date: Wed, 10 Mar 2021 08:33:19 +0100 +Subject: efi: use 32-bit alignment for efi_guid_t literals + +From: Ard Biesheuvel + +commit fb98cc0b3af2ba4d87301dff2b381b12eee35d7d upstream. + +Commit 494c704f9af0 ("efi: Use 32-bit alignment for efi_guid_t") updated +the type definition of efi_guid_t to ensure that it always appears +sufficiently aligned (the UEFI spec is ambiguous about this, but given +the fact that its EFI_GUID type is defined in terms of a struct carrying +a uint32_t, the natural alignment is definitely >= 32 bits). + +However, we missed the EFI_GUID() macro which is used to instantiate +efi_guid_t literals: that macro is still based on the guid_t type, +which does not have a minimum alignment at all. This results in warnings +such as + + In file included from drivers/firmware/efi/mokvar-table.c:35: + include/linux/efi.h:1093:34: warning: passing 1-byte aligned argument to + 4-byte aligned parameter 2 of 'get_var' may result in an unaligned pointer + access [-Walign-mismatch] + status = get_var(L"SecureBoot", &EFI_GLOBAL_VARIABLE_GUID, NULL, &size, + ^ + include/linux/efi.h:1101:24: warning: passing 1-byte aligned argument to + 4-byte aligned parameter 2 of 'get_var' may result in an unaligned pointer + access [-Walign-mismatch] + get_var(L"SetupMode", &EFI_GLOBAL_VARIABLE_GUID, NULL, &size, &setupmode); + +The distinction only matters on CPUs that do not support misaligned loads +fully, but 32-bit ARM's load-multiple instructions fall into that category, +and these are likely to be emitted by the compiler that built the firmware +for loading word-aligned 128-bit GUIDs from memory + +So re-implement the initializer in terms of our own efi_guid_t type, so that +the alignment becomes a property of the literal's type. + +Fixes: 494c704f9af0 ("efi: Use 32-bit alignment for efi_guid_t") +Reported-by: Nathan Chancellor +Reviewed-by: Nick Desaulniers +Reviewed-by: Nathan Chancellor +Tested-by: Nathan Chancellor +Link: https://github.com/ClangBuiltLinux/linux/issues/1327 +Signed-off-by: Ard Biesheuvel +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/efi.h | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/include/linux/efi.h ++++ b/include/linux/efi.h +@@ -63,8 +63,10 @@ typedef void *efi_handle_t; + */ + typedef guid_t efi_guid_t __aligned(__alignof__(u32)); + +-#define EFI_GUID(a,b,c,d0,d1,d2,d3,d4,d5,d6,d7) \ +- GUID_INIT(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) ++#define EFI_GUID(a, b, c, d...) (efi_guid_t){ { \ ++ (a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, ((a) >> 24) & 0xff, \ ++ (b) & 0xff, ((b) >> 8) & 0xff, \ ++ (c) & 0xff, ((c) >> 8) & 0xff, d } } + + /* + * Generic EFI table header diff --git a/queue-5.4/firmware-efi-fix-a-use-after-bug-in-efi_mem_reserve_persistent.patch b/queue-5.4/firmware-efi-fix-a-use-after-bug-in-efi_mem_reserve_persistent.patch new file mode 100644 index 00000000000..d9a361c6965 --- /dev/null +++ b/queue-5.4/firmware-efi-fix-a-use-after-bug-in-efi_mem_reserve_persistent.patch @@ -0,0 +1,40 @@ +From 9ceee7d0841a8f7d7644021ba7d4cc1fbc7966e3 Mon Sep 17 00:00:00 2001 +From: Lv Yunlong +Date: Wed, 10 Mar 2021 00:31:27 -0800 +Subject: firmware/efi: Fix a use after bug in efi_mem_reserve_persistent + +From: Lv Yunlong + +commit 9ceee7d0841a8f7d7644021ba7d4cc1fbc7966e3 upstream. + +In the for loop in efi_mem_reserve_persistent(), prsv = rsv->next +use the unmapped rsv. Use the unmapped pages will cause segment +fault. + +Fixes: 18df7577adae6 ("efi/memreserve: deal with memreserve entries in unmapped memory") +Signed-off-by: Lv Yunlong +Signed-off-by: Ard Biesheuvel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/firmware/efi/efi.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/firmware/efi/efi.c ++++ b/drivers/firmware/efi/efi.c +@@ -1006,7 +1006,7 @@ int __ref efi_mem_reserve_persistent(phy + } + + /* first try to find a slot in an existing linked list entry */ +- for (prsv = efi_memreserve_root->next; prsv; prsv = rsv->next) { ++ for (prsv = efi_memreserve_root->next; prsv; ) { + rsv = memremap(prsv, sizeof(*rsv), MEMREMAP_WB); + index = atomic_fetch_add_unless(&rsv->count, 1, rsv->size); + if (index < rsv->size) { +@@ -1016,6 +1016,7 @@ int __ref efi_mem_reserve_persistent(phy + memunmap(rsv); + return efi_mem_reserve_iomem(addr, size); + } ++ prsv = rsv->next; + memunmap(rsv); + } + diff --git a/queue-5.4/genirq-disable-interrupts-for-force-threaded-handlers.patch b/queue-5.4/genirq-disable-interrupts-for-force-threaded-handlers.patch new file mode 100644 index 00000000000..80d3f256373 --- /dev/null +++ b/queue-5.4/genirq-disable-interrupts-for-force-threaded-handlers.patch @@ -0,0 +1,70 @@ +From 81e2073c175b887398e5bca6c004efa89983f58d Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Wed, 17 Mar 2021 15:38:52 +0100 +Subject: genirq: Disable interrupts for force threaded handlers + +From: Thomas Gleixner + +commit 81e2073c175b887398e5bca6c004efa89983f58d upstream. + +With interrupt force threading all device interrupt handlers are invoked +from kernel threads. Contrary to hard interrupt context the invocation only +disables bottom halfs, but not interrupts. This was an oversight back then +because any code like this will have an issue: + +thread(irq_A) + irq_handler(A) + spin_lock(&foo->lock); + +interrupt(irq_B) + irq_handler(B) + spin_lock(&foo->lock); + +This has been triggered with networking (NAPI vs. hrtimers) and console +drivers where printk() happens from an interrupt which interrupted the +force threaded handler. + +Now people noticed and started to change the spin_lock() in the handler to +spin_lock_irqsave() which affects performance or add IRQF_NOTHREAD to the +interrupt request which in turn breaks RT. + +Fix the root cause and not the symptom and disable interrupts before +invoking the force threaded handler which preserves the regular semantics +and the usefulness of the interrupt force threading as a general debugging +tool. + +For not RT this is not changing much, except that during the execution of +the threaded handler interrupts are delayed until the handler +returns. Vs. scheduling and softirq processing there is no difference. + +For RT kernels there is no issue. + +Fixes: 8d32a307e4fa ("genirq: Provide forced interrupt threading") +Reported-by: Johan Hovold +Signed-off-by: Thomas Gleixner +Reviewed-by: Johan Hovold +Acked-by: Sebastian Andrzej Siewior +Link: https://lore.kernel.org/r/20210317143859.513307808@linutronix.de +Signed-off-by: Greg Kroah-Hartman +--- + kernel/irq/manage.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/kernel/irq/manage.c ++++ b/kernel/irq/manage.c +@@ -1026,11 +1026,15 @@ irq_forced_thread_fn(struct irq_desc *de + irqreturn_t ret; + + local_bh_disable(); ++ if (!IS_ENABLED(CONFIG_PREEMPT_RT)) ++ local_irq_disable(); + ret = action->thread_fn(action->irq, action->dev_id); + if (ret == IRQ_HANDLED) + atomic_inc(&desc->threads_handled); + + irq_finalize_oneshot(desc, action); ++ if (!IS_ENABLED(CONFIG_PREEMPT_RT)) ++ local_irq_enable(); + local_bh_enable(); + return ret; + } diff --git a/queue-5.4/series b/queue-5.4/series index c0c1ea40e1c..9c72e0c556f 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -55,3 +55,7 @@ x86-introduce-ts_compat_restart-to-fix-get_nr_restart_syscall.patch ext4-find-old-entry-again-if-failed-to-rename-whiteout.patch ext4-do-not-try-to-set-xattr-into-ea_inode-if-value-is-empty.patch ext4-fix-potential-error-in-ext4_do_update_inode.patch +efi-use-32-bit-alignment-for-efi_guid_t-literals.patch +firmware-efi-fix-a-use-after-bug-in-efi_mem_reserve_persistent.patch +genirq-disable-interrupts-for-force-threaded-handlers.patch +x86-apic-of-fix-cpu-devicetree-node-lookups.patch diff --git a/queue-5.4/x86-apic-of-fix-cpu-devicetree-node-lookups.patch b/queue-5.4/x86-apic-of-fix-cpu-devicetree-node-lookups.patch new file mode 100644 index 00000000000..ce237d12b0b --- /dev/null +++ b/queue-5.4/x86-apic-of-fix-cpu-devicetree-node-lookups.patch @@ -0,0 +1,51 @@ +From dd926880da8dbbe409e709c1d3c1620729a94732 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Fri, 12 Mar 2021 10:20:33 +0100 +Subject: x86/apic/of: Fix CPU devicetree-node lookups + +From: Johan Hovold + +commit dd926880da8dbbe409e709c1d3c1620729a94732 upstream. + +Architectures that describe the CPU topology in devicetree and do not have +an identity mapping between physical and logical CPU ids must override the +default implementation of arch_match_cpu_phys_id(). + +Failing to do so breaks CPU devicetree-node lookups using of_get_cpu_node() +and of_cpu_device_node_get() which several drivers rely on. It also causes +the CPU struct devices exported through sysfs to point to the wrong +devicetree nodes. + +On x86, CPUs are described in devicetree using their APIC ids and those +do not generally coincide with the logical ids, even if CPU0 typically +uses APIC id 0. + +Add the missing implementation of arch_match_cpu_phys_id() so that CPU-node +lookups work also with SMP. + +Apart from fixing the broken sysfs devicetree-node links this likely does +not affect current users of mainline kernels on x86. + +Fixes: 4e07db9c8db8 ("x86/devicetree: Use CPU description from Device Tree") +Signed-off-by: Johan Hovold +Signed-off-by: Thomas Gleixner +Link: https://lore.kernel.org/r/20210312092033.26317-1-johan@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/apic/apic.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/arch/x86/kernel/apic/apic.c ++++ b/arch/x86/kernel/apic/apic.c +@@ -2354,6 +2354,11 @@ static int cpuid_to_apicid[] = { + [0 ... NR_CPUS - 1] = -1, + }; + ++bool arch_match_cpu_phys_id(int cpu, u64 phys_id) ++{ ++ return phys_id == cpuid_to_apicid[cpu]; ++} ++ + #ifdef CONFIG_SMP + /** + * apic_id_is_primary_thread - Check whether APIC ID belongs to a primary thread