Re: [PATCH v6 4/4] x86/irq, iommu/amd, x86/hyperv, PCI: Drop redundant irq_retrigger inits

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] irq: lost interrupts during CPU hotplug due to skipped top-level chip in fixup_irqs()
--

commit 7fb72a647b56b7209b19850bb988eed0fff8563c
Author: Naman Jain [off-list ref]

x86/irq, iommu/amd, x86/hyperv, PCI: Drop redundant irq_retrigger inits

This commit removes the redundant irq_retrigger() initializations from the
outermost domain interrupt chips. The commit message notes this is because
fixup_irqs() and msi_set_affinity() now use irq_chip_retrigger_hierarchy().

    With fixup_irqs() and msi_set_affinity() now using
    irq_chip_retrigger_hierarchy(), the outermost domain chips no longer need
    the helper as their irq_retrigger() callback. The generic resend path
    already uses the hierarchy helper.

[Severity: High]
Can the transition to using irq_chip_retrigger_hierarchy() directly in
fixup_irqs() result in a regression where hardware interrupts are lost
during CPU hotplug?

When a CPU is taken offline, fixup_irqs() is called to migrate and
retrigger pending interrupts. It retrieves the top-level irq_data and calls
irq_chip_retrigger_hierarchy():

arch/x86/kernel/irq.c:fixup_irqs() {
    ...
    data = irq_desc_get_irq_data(desc);
    ret = irq_chip_retrigger_hierarchy(data);
    ...
}

However, irq_chip_retrigger_hierarchy() is designed to be used as a chip
callback, so it unconditionally starts its search at data->parent_data,
skipping the top-level chip itself:

kernel/irq/chip.c:irq_chip_retrigger_hierarchy() {
    ...
    for (data = data->parent_data; data; data = data->parent_data)
        if (data->chip && data->chip->irq_retrigger)
    ...
}

If an interrupt is non-hierarchical (e.g., directly managed by
lapic_controller in the root x86_vector_domain), it has no parent
(parent_data == NULL).

Will the retrigger loop fail to execute, returning 0 without calling
apic_retrigger_irq(), and silently dropping the pending interrupt?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923043023.3150498-1-namjain@linux.microsoft.com?part=4