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 <[email protected]> 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/[email protected]?part=4
