Re: [PATCH for-rc v2 8/8] RDMA/bnxt_re: Check is_in_used before trusting RCFW completion

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Duplicate completions for retired internal commands bypass the is_in_used gate, causing timeout_send atomic underflow.
--

commit a5d91fba60b82a58962973687dc528a6bc7de745
Author: Selvin Xavier <selvin.xavier@broadcom.com>

RDMA/bnxt_re: Check is_in_used before trusting RCFW completion

This commit gates crsqe->resp memory copies and timed-out AH destruction on
is_in_used to prevent operating on stale responses. It also disarms waiters
and clears the response pointer when bailing out early on a detached device.

> diff --git a/drivers/infiniband/hw/bnxt_re/qplib_rcfw.c b/drivers/infiniband/hw/bnxt_re/qplib_rcfw.c
> index 9ee0d500436cb..0339e55bea886 100644
> --- a/drivers/infiniband/hw/bnxt_re/qplib_rcfw.c
> +++ b/drivers/infiniband/hw/bnxt_re/qplib_rcfw.c
[ ... ]
> @@ -682,7 +685,7 @@ static int bnxt_qplib_process_qp_event(struct bnxt_qplib_rcfw *rcfw,
>  		if (crsqe->is_internal_cmd && !qp_event->status)
>  			atomic_dec(&rcfw->timeout_send);

[Severity: High]
This isn't a bug introduced by this patch, but does this atomic_dec() in
bnxt_qplib_process_qp_event() need the same is_in_used check that was added
below?

If a late or duplicate firmware completion arrives for an already-retired
internal command, it will bypass the is_in_used gate here. Can this execute an
erroneous atomic_dec() on a stale response and cause the timeout_send counter
to underflow?

> -		if (crsqe->is_waiter_alive) {
> +		if (crsqe->is_waiter_alive && crsqe->is_in_used) {
>  			if (crsqe->resp) {
>  				memcpy(crsqe->resp, qp_event, sizeof(*qp_event));
>  				/* Insert write memory barrier to ensure that

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909135244.122747-1-selvin.xavier@broadcom.com?part=8