arch related major backported bugfix patches before 2023
Mark Rutland (1): irqchip/gic-v3: Ensure pseudo-NMIs have an ISB between ack and handling
Sergey Shtylyov (1): genirq/ipi: Fix NULL pointer deref in irq_data_get_affinity_mask()
Thomas Gleixner (1): x86/ioapic: Unbreak check_timer()
arch/x86/kernel/apic/io_apic.c | 1 + drivers/irqchip/irq-gic-v3.c | 3 +++ kernel/irq/ipi.c | 8 ++++++-- 3 files changed, 10 insertions(+), 2 deletions(-)
From: Sergey Shtylyov s.shtylyov@omp.ru
mainline inclusion from mainline-v6.3-rc1 commit feabecaff5902f896531dde90646ca5dfa9d4f7d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9OZI6
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
--------------------------------
If ipi_send_{mask|single}() is called with an invalid interrupt number, all the local variables there will be NULL. ipi_send_verify() which is invoked from these functions does verify its 'data' parameter, resulting in a kernel oops in irq_data_get_affinity_mask() as the passed NULL pointer gets dereferenced.
Add a missing NULL pointer check in ipi_send_verify()...
Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.
Fixes: 3b8e29a82dd1 ("genirq: Implement ipi_send_mask/single()") Signed-off-by: Sergey Shtylyov s.shtylyov@omp.ru Signed-off-by: Thomas Gleixner tglx@linutronix.de Link: https://lore.kernel.org/r/b541232d-c2b6-1fe9-79b4-a7129459e4d0@omp.ru
Conflicts: kernel/irq/ipi.c [This conflict is caused by unmatched context]
Singed-off-by: Liao Chen liaochen4@huawei.com --- kernel/irq/ipi.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/irq/ipi.c b/kernel/irq/ipi.c index 8b778e37dc6d..0ca1331546e2 100644 --- a/kernel/irq/ipi.c +++ b/kernel/irq/ipi.c @@ -186,9 +186,9 @@ EXPORT_SYMBOL_GPL(ipi_get_hwirq); static int ipi_send_verify(struct irq_chip *chip, struct irq_data *data, const struct cpumask *dest, unsigned int cpu) { - struct cpumask *ipimask = irq_data_get_affinity_mask(data); + struct cpumask *ipimask;
- if (!chip || !ipimask) + if (!chip || !data) return -EINVAL;
if (!chip->ipi_send_single && !chip->ipi_send_mask) @@ -197,6 +197,10 @@ static int ipi_send_verify(struct irq_chip *chip, struct irq_data *data, if (cpu >= nr_cpu_ids) return -EINVAL;
+ ipimask = irq_data_get_affinity_mask(data); + if (!ipimask) + return -EINVAL; + if (dest) { if (!cpumask_subset(dest, ipimask)) return -EINVAL;
From: Mark Rutland mark.rutland@arm.com
mainline inclusion from mainline-v5.19-rc1 commit adf14453d2c037ab529040c1186ea32e277e783a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9OZI6
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
--------------------------------
There are cases where a context synchronization event is necessary between an IRQ being raised and being handled, and there are races such that we cannot rely upon the exception entry being subsequent to the interrupt being raised.
We identified and fixes this for regular IRQs in commit:
39a06b67c2c1256b ("irqchip/gic: Ensure we have an ISB between ack and ->handle_irq")
Unfortunately, we forgot to do the same for psuedo-NMIs when support for those was added in commit:
f32c926651dcd168 ("irqchip/gic-v3: Handle pseudo-NMIs")
Which means that when pseudo-NMIs are used for PMU support, we'll hit the same problem.
Apply the same fix as for regular IRQs. Note that when EOI mode 1 is in use, the call to gic_write_eoir() will provide an ISB.
Fixes: f32c926651dcd168 ("irqchip/gic-v3: Handle pseudo-NMIs") Signed-off-by: Mark Rutland mark.rutland@arm.com Cc: Marc Zyngier maz@kernel.org Cc: Thomas Gleixner tglx@linutronix.de Cc: Will Deacon will.deacon@arm.com Signed-off-by: Marc Zyngier maz@kernel.org Link: https://lore.kernel.org/r/20220513133038.226182-2-mark.rutland@arm.com Signed-off-by: Liao Chen liaochen4@huawei.com --- drivers/irqchip/irq-gic-v3.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c index 5d8658749c8c..26dddaa9f01a 100644 --- a/drivers/irqchip/irq-gic-v3.c +++ b/drivers/irqchip/irq-gic-v3.c @@ -498,6 +498,9 @@ static inline void gic_handle_nmi(u32 irqnr, struct pt_regs *regs)
if (static_branch_likely(&supports_deactivate_key)) gic_write_eoir(irqnr); + else + isb(); + /* * Leave the PSR.I bit set to prevent other NMIs to be * received while handling this one.
From: Thomas Gleixner tglx@linutronix.de
mainline inclusion from mainline-v5.19-rc1 commit adf14453d2c037ab529040c1186ea32e277e783a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9OZI6
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
--------------------------------
Several people reported in the kernel bugzilla that between v4.12 and v4.13 the magic which works around broken hardware and BIOSes to find the proper timer interrupt delivery mode stopped working for some older affected platforms which need to fall back to ExtINT delivery mode.
The reason is that the core code changed to keep track of the masked and disabled state of an interrupt line more accurately to avoid the expensive hardware operations.
That broke an assumption in i8259_make_irq() which invokes
disable_irq_nosync(); irq_set_chip_and_handler(); enable_irq();
Up to v4.12 this worked because enable_irq() unconditionally unmasked the interrupt line, but after the state tracking improvements this is not longer the case because the IO/APIC uses lazy disabling. So the line state is unmasked which means that enable_irq() does not call into the new irq chip to unmask it.
In principle this is a shortcoming of the core code, but it's more than unclear whether the core code should try to reset state. At least this cannot be done unconditionally as that would break other existing use cases where the chip type is changed, e.g. when changing the trigger type, but the callers expect the state to be preserved.
As the way how check_timer() is switching the delivery modes is truly unique, the obvious fix is to simply unmask the i8259 manually after changing the mode to ExtINT delivery and switching the irq chip to the legacy PIC.
Note, that the fixes tag is not really precise, but identifies the commit which broke the assumptions in the IO/APIC and i8259 code and that's the kernel version to which this needs to be backported.
Fixes: bf22ff45bed6 ("genirq: Avoid unnecessary low level irq function calls") Reported-by: p_c_chan@hotmail.com Reported-by: ecm4@mail.com Reported-by: perdigao1@yahoo.com Reported-by: matzes@users.sourceforge.net Reported-by: rvelascog@gmail.com Signed-off-by: Thomas Gleixner tglx@linutronix.de Tested-by: p_c_chan@hotmail.com Tested-by: matzes@users.sourceforge.net Cc: stable@vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=197769 Signed-off-by: Liao Chen liaochen4@huawei.com --- arch/x86/kernel/apic/io_apic.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index a6397da20b28..a63366344fcf 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -2256,6 +2256,7 @@ static inline void __init check_timer(void) legacy_pic->init(0); legacy_pic->make_irq(0); apic_write(APIC_LVT0, APIC_DM_EXTINT); + legacy_pic->unmask(0);
unlock_ExtINT_logic();
反馈: 您发送到kernel@openeuler.org的补丁/补丁集,已成功转换为PR! PR链接地址: https://gitee.com/openeuler/kernel/pulls/8100 邮件列表地址:https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/N...
FeedBack: The patch(es) which you have sent to kernel@openeuler.org mailing list has been converted to a pull request successfully! Pull request link: https://gitee.com/openeuler/kernel/pulls/8100 Mailing list address: https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/N...