--- /dev/null
+From fb98cc0b3af2ba4d87301dff2b381b12eee35d7d Mon Sep 17 00:00:00 2001
+From: Ard Biesheuvel <ardb@kernel.org>
+Date: Wed, 10 Mar 2021 08:33:19 +0100
+Subject: efi: use 32-bit alignment for efi_guid_t literals
+
+From: Ard Biesheuvel <ardb@kernel.org>
+
+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 <nathan@kernel.org>
+Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
+Reviewed-by: Nathan Chancellor <nathan@kernel.org>
+Tested-by: Nathan Chancellor <nathan@kernel.org>
+Link: https://github.com/ClangBuiltLinux/linux/issues/1327
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From 9ceee7d0841a8f7d7644021ba7d4cc1fbc7966e3 Mon Sep 17 00:00:00 2001
+From: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
+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 <lyl2019@mail.ustc.edu.cn>
+
+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 <lyl2019@mail.ustc.edu.cn>
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
+
--- /dev/null
+From 81e2073c175b887398e5bca6c004efa89983f58d Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Wed, 17 Mar 2021 15:38:52 +0100
+Subject: genirq: Disable interrupts for force threaded handlers
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+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 <johan@kernel.org>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Johan Hovold <johan@kernel.org>
+Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Link: https://lore.kernel.org/r/20210317143859.513307808@linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
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
--- /dev/null
+From dd926880da8dbbe409e709c1d3c1620729a94732 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Fri, 12 Mar 2021 10:20:33 +0100
+Subject: x86/apic/of: Fix CPU devicetree-node lookups
+
+From: Johan Hovold <johan@kernel.org>
+
+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 <johan@kernel.org>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Link: https://lore.kernel.org/r/20210312092033.26317-1-johan@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
projects / thirdparty / kernel / stable-queue.git / commitdiff
