Re: [PATCH v3 10/14] lpfc: Remove slowpath cqe process limiter in slow ring event handler

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Removing the 64 CQE process limiter creates a structurally verified infinite loop when processing MDS Loopback or unsolicited data frames under resource exhaustion, leading to CPU soft lockups.
- [Medium] Mismatch between the commit message's stated log threshold (64) and the actual implemented code (256).
--

--- Patch [10]: [PATCH v3 10/14] lpfc: Remove slowpath cqe process limiter in slow ring event handler ---
commit 69f6839c38e91e160d808d1e850edd0295006605
Author: Justin Tee <justintee8345@gmail.com>

lpfc: Remove slowpath cqe process limiter in slow ring event handler

This patch removes the 64 CQE processing limit in the slow ring event
handler to prevent delayed processing penalties during large SAN
rediscoveries. It replaces the hard limit with an unbounded loop that 
drains the queue and adds diagnostic logging.

> Remove the slowpath cqe process limiter in
> lpfc_sli_handle_slow_ring_event_s4 to ensure the slow path CQ is drained.
> Add log messages to notify when the 64 cqe count is reached.

[Severity: Medium]
The commit message states the log messages notify when the 64 CQE count
is reached, but the implementation uses LPFC_WQE_DEF_COUNT (which is 256).

Could the commit message be updated to match the code, or should the code
be using 64?

> diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
> --- a/drivers/scsi/lpfc/lpfc_sli.c
> +++ b/drivers/scsi/lpfc/lpfc_sli.c
> @@ -4527,7 +4527,7 @@ lpfc_sli_handle_slow_ring_event_s4(struct lpfc_hba *phba,
>  	struct hbq_dmabuf *dmabuf;
>  	struct lpfc_cq_event *cq_event;
>  	unsigned long iflag;
> -	int count = 0;
> +	u32 count = 0;
>  
>  	clear_bit(HBA_SP_QUEUE_EVT, &phba->hba_flag);
>  	while (!list_empty(&phba->sli4_hba.sp_queue_event)) {

[Severity: High]
Could removing the event limit here lead to an infinite loop and a CPU soft
lockup under resource exhaustion?

If an MDS loopback frame or unsolicited data frame is received while the
driver's IOCB pool is exhausted, lpfc_sli4_handle_mds_loopback() fails
to allocate an IOCB and puts the event back on the tail of the exact queue
being drained:

lpfc_sli4_handle_mds_loopback() {
    ...
    list_add_tail(&dmabuf->cq_event.list,
                  &phba->sli4_hba.sp_queue_event);
    ...
}

Since the loop in lpfc_sli_handle_slow_ring_event_s4() no longer breaks at 64
events and doesn't yield, it seems the requeued event will be immediately
dequeued again. Because the kthread never yields to allow IOs to complete,
does the IOCB pool remain permanently exhausted while it infinitely requeues
the same event?

[ ... ]

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