Re: [PATCH v2 4/4] cxl/events: Return IRQ_NONE when no events were processed

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Concurrent execution of the shared IRQ thread for different CXL event vectors will incorrectly return IRQ_NONE, causing the kernel to permanently disable the IRQ.
--

commit e4fb9fa2ad67f892cc6a1e121480e607bbf7ed82
Author: Anisa Su <anisa.su887@gmail.com>

cxl/events: Return IRQ_NONE when no events were processed

This commit changes cxl_event_thread() to return IRQ_NONE when no events
are processed, rather than always returning IRQ_HANDLED. The stated intent
is to allow the kernel to detect devices flooding their MSI vectors.

> diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c
> index 239df18c9c87b..94ff2b7d1f09a 100644
> --- a/drivers/cxl/pci.c
> +++ b/drivers/cxl/pci.c
> @@ -528,6 +528,7 @@ static irqreturn_t cxl_event_thread(int irq, void *id)
>  	struct cxl_memdev_state *mds = to_cxl_memdev_state(cxlds);
>  	u32 mask = CXLDEV_EVENT_STATUS_ALL;
>  	int attempts = CXL_EVENT_DRAIN_ATTEMPTS;
> +	bool handled = false;
>  
>  	while (mask) {
>  		u32 status, drained, stuck;
[ ... ]
> @@ -542,6 +543,7 @@ static irqreturn_t cxl_event_thread(int irq, void *id)
>  		status &= mask;
>  		if (!status)
>  			break;
> +		handled = true;
>  
>  		rc = cxl_mem_get_event_records(mds, status, &drained);
>  		if (rc) {
[ ... ]
> @@ -579,7 +581,7 @@ static irqreturn_t cxl_event_thread(int irq, void *id)
>  		cond_resched();
>  	}
>  
> -	return IRQ_HANDLED;
> +	return handled ? IRQ_HANDLED : IRQ_NONE;
>  }

[Severity: High]
Will this cause concurrent event interrupts on multi-vector devices to be
permanently disabled?

If a CXL device maps different event logs to different MSI vectors (for
example, Info to vector 1 and Warn to vector 2), and both events occur in
quick succession, the first handler thread will drain both logs because
mask is initialized to CXLDEV_EVENT_STATUS_ALL.

When the second handler thread wakes up, it will read a status of 0, break
the loop without setting handled to true, and return IRQ_NONE.

Could this trigger the kernel's spurious interrupt detector during normal
operation under load, causing it to permanently disable the IRQ and break
hardware event reporting?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901002912.958-1-anisa.su@samsung.com?part=4