Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] cxl: infinite loop in cxl_event_thread() on device surprise removal --
commit 84b381be3cde0a84228cae787a5be8a35384cffd Author: Ira Weiny <[email protected]> cxl/mem: Configure dynamic capacity interrupts Dynamic Capacity Devices (DCD) support extent change notifications through the event log mechanism. The interrupt mailbox commands were extended in CXL 3.1 to support these notifications. Firmware can't configure DCD events to be FW controlled but can retain control of memory events. > diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c > index 7b754af2168d0..d2bed92be30df 100644 > --- a/drivers/cxl/pci.c > +++ b/drivers/cxl/pci.c [ ... ] > @@ -523,8 +534,8 @@ static irqreturn_t cxl_event_thread(int irq, void *id) > * ignore the reserved upper 32 bits > */ > status = readl(cxlds->regs.status + > CXLDEV_DEV_EVENT_STATUS_OFFSET); > - /* Ignore logs unknown to the driver */ > - status &= CXLDEV_EVENT_STATUS_ALL; > + /* Ignore logs unknown to the driver or owned by BIOS */ > + status &= mask; > if (!status) > break; > cxl_mem_get_event_records(mds, status); > cond_resched(); > } while (status); [Severity: High] If the CXL device is surprise-removed or its PCIe link goes down, readl() will return ~0U. Since this is masked with a non-zero bitmask, could this result in an infinite loop? If the loop does not break, the IRQ thread could consume 100% of a CPU core and prevent the PCI removal path from completing. Should there be a check for status == ~0U to break out of the loop? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=6
