Re: [PATCH v4 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 1 potential issue(s) to consider:
- [High] scsi: lpfc: CPU soft lockup in lpfc_sli_handle_slow_ring_event_s4()
--

commit 2c325e87e41c5052e2704f826b9f808f153d5397
Author: Nigel Kirkland <nkirkland2304@gmail.com>

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

This commit removes the 64 CQE limit in the slow path event handler
to ensure the slow path CQ is drained completely. It also adds logging 
when the CQE count reaches a full ELS WQ wrap.

> diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
> index 10d9030a1e883..06dc01c9539ed 100644
> --- a/drivers/scsi/lpfc/lpfc_sli.c
> +++ b/drivers/scsi/lpfc/lpfc_sli.c

[ ... ]

> @@ -4562,22 +4562,39 @@ lpfc_sli_handle_slow_ring_event_s4(struct lpfc_hba *phba,
>  			if (irspiocbq)
>  				lpfc_sli_sp_handle_rspiocb(phba, pring,
>  							   irspiocbq);
> -			count++;
>  			break;
>  		case CQE_CODE_RECEIVE:
>  		case CQE_CODE_RECEIVE_V1:
>  			dmabuf = container_of(cq_event, struct hbq_dmabuf,
>  					      cq_event);
>  			lpfc_sli4_handle_received_buffer(phba, dmabuf);
> -			count++;
>  			break;
>  		default:
> +			lpfc_printf_log(phba, KERN_INFO, LOG_ELS,
> +					"7771 Unknown WCQE completion code "
> +					"x%x, ignoring.\n",
> +					bf_get(lpfc_wcqe_c_code,
> +					       &cq_event->cqe.wcqe_cmpl));
>  			break;
>  		}
>  
> -		/* Limit the number of events to 64 to avoid soft lockups */
> -		if (count == 64)
> -			break;

[Severity: High]
Could removing this limit cause a CPU soft lockup under certain failure
conditions?

When an MDS loopback or unsolicited data frame is received (CQE_CODE_RECEIVE),
and the driver's IOCBQ pool is momentarily empty,
lpfc_sli4_handle_mds_loopback() fails to allocate an iocbq via
lpfc_sli_get_iocbq() and adds the event back to the sp_queue_event list:

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

Since this patch removes the 64-iteration limit, this while loop no
longer yields. It will immediately dequeue the same event and retry the
allocation in a tight spin loop. Without the loop break, the worker
thread can no longer reach wait_event_interruptible() to yield the CPU,
resulting in a 100% CPU lockup.

Is there another mechanism to prevent the loop from spinning infinitely 
when events are requeued?

> +		/* This loop runs until the ELS/CT CQ is empty.  Post a one
> +		 * time message for debug support when ELS WQ ecount
> +		 * completions are processed - this represent 1 full ELS WQ
> +		 * wrap.
> +		 */
> +		if (++count == LPFC_WQE_DEF_COUNT) {
> +			lpfc_printf_log(phba, KERN_INFO, LOG_ELS,
> +					"7772 %s SP CQE count %d\n",
> +					__func__, count);
> +		}
> +	}
> +
> +	/* Log a final message to note how many CQEs were processed. */
> +	if (count > LPFC_WQE_DEF_COUNT) {
> +		lpfc_printf_log(phba, KERN_INFO, LOG_ELS,
> +				"7773 %s SP CQEs complete, count %d\n",
> +				__func__, count);
>  	}
>  }

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