[PATCH v2] cxl/events: Return IRQ_NONE when no event is pending

[PATCH v2] cxl/events: Return IRQ_NONE when no event is pending

[Shaikh Kamaluddin]

CXL event interrupts may share an MSI/MSI-X vector with other event
logs or device features. Consequently, cxl_event_thread() is registered
with IRQF_SHARED and must determine whether the event-log facility
claimed the interrupt.

The handler masks the Device Event Status register to the event logs
supported by the driver. However, when no supported status bit is set,
it exits the processing loop and still returns IRQ_HANDLED. This
incorrectly reports that the interrupt was claimed and prevents the
generic spurious-interrupt detector from accounting it as unhandled.

Track whether the CXL event handler claimed the interrupt and return
IRQ_NONE when no supported event is detected. If no handler sharing the
vector claims a sustained interrupt storm, the generic spurious-
interrupt detector can eventually identify and disable the affected
IRQ.

Signed-off-by: Shaikh Kamaluddin <shaikhkamal2012@gmail.com>
---
Changes in V2:
- Emphasize that returning IRQ_NONE enables generic spurious-interrupt
  detection and drop the Fixes tag. (Jonathan Cameron)
- Check whether the event interrupt is already disabled by Anisa Su's
  patch; no code changes were needed. (Ben Cheatham)
- Rebase onto v7.3-rc2; no code changes.

 drivers/cxl/pci.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c
index c7c91e8dc51d..8b560cae91f2 100644
--- a/drivers/cxl/pci.c
+++ b/drivers/cxl/pci.c
@@ -515,6 +515,7 @@ static irqreturn_t cxl_event_thread(int irq, void *id)
 	struct cxl_dev_id *dev_id = id;
 	struct cxl_dev_state *cxlds = dev_id->cxlds;
 	struct cxl_memdev_state *mds = to_cxl_memdev_state(cxlds);
+	bool handled = false;
 	u32 status;
 
 	do {
@@ -527,11 +528,13 @@ static irqreturn_t cxl_event_thread(int irq, void *id)
 		status &= CXLDEV_EVENT_STATUS_ALL;
 		if (!status)
 			break;
+
+		handled = true;
 		cxl_mem_get_event_records(mds, status);
 		cond_resched();
 	} while (status);
 
-	return IRQ_HANDLED;
+	return handled ? IRQ_HANDLED : IRQ_NONE;
 }
 
 static int cxl_event_req_irq(struct cxl_dev_state *cxlds, u8 setting)

base-commit: df2908090cda368b01ff43709f51890076c56157
-- 
2.43.0

Re: [PATCH v2] cxl/events: Return IRQ_NONE when no event is pending

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] The threaded IRQ handler `cxl_event_thread()` can enter an infinite loop if mailbox commands fail to clear event records on the device, or if a PCIe surprise removal causes the MMIO read to persistently return all 1s (~0U).
- [High] The driver blindly trusts the `record_count` and `count` fields returned by the device in mailbox payloads, leading to out-of-bounds kernel memory reads and potential information leaks.
--

commit 659b756fc25aa4e783ce4a882044a537d7b5d643
Author: Shaikh Kamaluddin <shaikhkamal2012@gmail.com>

cxl/events: Return IRQ_NONE when no event is pending

This patch tracks whether the CXL event handler claimed the interrupt and
returns IRQ_NONE when no supported event is detected. This allows the generic
spurious-interrupt detector to identify and disable the affected IRQ during
interrupt storms where no handler claims the event.

> diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c
> index c7c91e8dc51dc..8b560cae91f2e 100644
> --- a/drivers/cxl/pci.c
> +++ b/drivers/cxl/pci.c
[ ... ]
> @@ -515,6 +515,7 @@ static irqreturn_t cxl_event_thread(int irq, void *id)
>  	struct cxl_dev_id *dev_id = id;
>  	struct cxl_dev_state *cxlds = dev_id->cxlds;
>  	struct cxl_memdev_state *mds = to_cxl_memdev_state(cxlds);
> +	bool handled = false;
>  	u32 status;
>  
>  	do {
>  		/*
>  		 * CXL 3.0 8.2.8.3.1: The lower 32 bits are the status;
>  		 * 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;
>  		if (!status)
>  			break;

[Severity: High]
This is a pre-existing issue, but can this loop become infinite if a PCIe
surprise removal or fatal device error occurs?

If readl() returns all 1s (~0U), status & CXLDEV_EVENT_STATUS_ALL will
still evaluate to a non-zero value, passing the if (!status) check. The
handler will then call into cxl_mem_get_event_records() where mailbox
commands will fail on the removed device, exiting without clearing the
hardware event status.

Since status is never cleared and the error handling doesn't break the
loop, this evaluates to true at the while (status) condition and repeats
indefinitely. Does this IRQF_ONESHOT threaded handler need to check for ~0U
to avoid monopolizing a CPU and preventing device teardown during hotplug
removal?

> +
> +		handled = true;
>  		cxl_mem_get_event_records(mds, status);

[Severity: High]
This isn't a bug introduced by this patch, but does this code blindly trust
the record_count returned by the device hardware?

When cxl_mem_get_event_records() calls into cxl_mem_get_records_log(), the
driver reads the count directly from the untrusted payload:

drivers/cxl/core/mbox.c:cxl_mem_get_records_log() {
    ...
    nr_rec = le16_to_cpu(payload->record_count);
    ...
    for (i = 0; i < nr_rec; i++)
        __cxl_event_trace_record(cxlmd, type, &payload->records[i]);
    ...
}

If a compromised or malicious CXL device returns an artificially large
record_count, could this read out-of-bounds kernel memory and leak it to
userspace via tracing? 

The same pattern appears in cxl_clear_event_record() and
cxl_mem_get_poison(), where the untrusted count is used as a loop bound.
Should the payload size be validated against mbox_cmd.size_out or the
maximum allocated buffer size before iterating?

>  		cond_resched();
>  	} while (status);
>  
> -	return IRQ_HANDLED;
> +	return handled ? IRQ_HANDLED : IRQ_NONE;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260912093815.14455-1-shaikhkamal2012@gmail.com?part=1