On Sun, Aug 30, 2026 at 08:28:28PM +0000, Priyank Rathod wrote: > If is_error_source() matches a device purely by Requester/Completer ID > match (e_info->id == pci_dev_id(dev)), the device is added to e_info->dev[] > even if it lacks the AER extended capability (dev->aer_cap == 0).
Hallucination, we do not enable error reporting on devices without AER capability, see pci_aer_init(). > Later, during aer_process_err_devices(), aer_get_device_error_info() > returns 0 when dev->aer_cap is 0 (or if no active error status is read), The "no active error status is read" is the only scenario where this *could* happen. However if no error bits are set in the status register, why did the device send an error message upstream in the first place? That would be a broken device. Another theoretical possibility would be that the device becomes inaccessible by the time aer_get_device_error_info() reads the status/mask registers. They'd both be read as "all ones", hence info->status & ~info->mask == 0. > On the ID-match fast path (a), is_error_source() returns true without > checking whether the device implements the AER extended capability > (dev->aer_cap != 0). This creates a real, non-exotic situation in several > common hardware topologies and operational states: Hallucination, this is by no means "real, non-exotic", it's an unlikely corner case. Thanks, Lukas
