Re: [PATCH 2/3] x86/irq: Use irq_chip_retrigger_hierarchy() in fixup_irqs()
[email protected] Tue, 28 Jul 2026 14:03:23 +0000
| Newsgroups | org.kernel.vger.linux-hyperv,org.kernel.vger.linux-pci |
|---|---|
| Message-ID | <[email protected]> |
Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [High] The patch replaces the direct invocation of the outermost chip's i= rq_retrigger() callback with irq_chip_retrigger_hierarchy(). However, irq_c= hip_retrigger_hierarchy() initializes its loop with `data =3D data->parent_= data`, completely skipping the outermost chip. This breaks interrupt retrig= gering for flat domains (like native lapic_controller) and any hierarchical= domain where the outermost chip directly implements the retrigger callback. -- --- Patch [2]: [PATCH 2/3] x86/irq: Use irq_chip_retrigger_hierarchy() in f= ixup_irqs() --- commit f97e883de2f6626561de48c426194caa41c3e062 Author: Naman Jain <[email protected]> x86/irq: Use irq_chip_retrigger_hierarchy() in fixup_irqs() This commit modifies fixup_irqs() to use irq_chip_retrigger_hierarchy() instead of invoking the outermost domain chip's irq_retrigger() callback directly. It also refactors the loop to use scoped guards for the irq descriptor lock. > diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c > index 30122f0b3af96..ef1bdd3c4659a 100644 > --- a/arch/x86/kernel/irq.c > +++ b/arch/x86/kernel/irq.c [ ... ] > @@ -489,22 +484,18 @@ void fixup_irqs(void) [ ... ] > - for (vector =3D FIRST_EXTERNAL_VECTOR; vector < NR_VECTORS; vector++) { > - if (IS_ERR_OR_NULL(__this_cpu_read(vector_irq[vector]))) > + for (unsigned int vector =3D FIRST_EXTERNAL_VECTOR; vector < NR_VECTORS= ; vector++) { > + struct irq_desc *desc =3D __this_cpu_read(vector_irq[vector]); > + > + if (IS_ERR_OR_NULL(desc)) > continue; > =20 > if (is_vector_pending(vector)) { > - desc =3D __this_cpu_read(vector_irq[vector]); > - > - raw_spin_lock(&desc->lock); > - data =3D irq_desc_get_irq_data(desc); > - chip =3D irq_data_get_irq_chip(data); > - if (chip->irq_retrigger) { > - chip->irq_retrigger(data); > + guard(raw_spinlock)(&desc->lock); > + if (irq_chip_retrigger_hierarchy(&desc->irq_data)) [Severity: High] Will this skip the outermost chip and cause a regression for flat domains? Looking at kernel/irq/chip.c:irq_chip_retrigger_hierarchy(), the loop initializes by immediately moving to the parent_data: int irq_chip_retrigger_hierarchy(struct irq_data *data) { for (data =3D data->parent_data; data; data =3D data->parent_data) if (data->chip && data->chip->irq_retrigger) return data->chip->irq_retrigger(data); return 0; } By passing &desc->irq_data directly to this function, it seems any retrigger callback on the outermost chip itself will be bypassed. Could this lead to dropped hardware interrupts during CPU hot-unplug for flat domains (like native lapic_controller) or any hierarchical domain where the outermost chip implements the retrigger callback? > __this_cpu_write(vector_irq[vector], VECTOR_RETRIGGERED); > - } > - raw_spin_unlock(&desc->lock); > } --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260728135117.2888= [email protected]?part=3D2