Re: [PATCH rdma-next v3 09/10] RDMA/mana_ib: Handle error CQEs for RC QPs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] RDMA/mana_ib: Inverted RC QP shadow queue mapping for GDMA receive errors
- [High] RDMA/mana_ib: QP lookup drops error CQEs for RC RREQ and RRESP queues
--

commit e1f8a51fcdc185eb1ad07f40a479febe1cbab173
Author: Konstantin Taranov <kotaranov@microsoft.com>

RDMA/mana_ib: Handle error CQEs for RC QPs

This commit decodes hardware error CQEs and processes them on the
corresponding work queue, completing the failing shadow entry with the
vendor status. It also defers transitioning RC QPs to the ERR state to
allow other work queues to be flushed.

> diff --git a/drivers/infiniband/hw/mana/cq.c b/drivers/infiniband/hw/mana/cq.c
> index f3002324754f7..18c8e8a98bb58 100644
> --- a/drivers/infiniband/hw/mana/cq.c
> +++ b/drivers/infiniband/hw/mana/cq.c

[ ... ]

> @@ -490,6 +513,71 @@ static bool handle_psn_cqe(struct mana_ib_qp *qp, u32 psn,
>  	return consumed;
>  }
>  
> +static bool mana_cqe_is_send(struct mana_ib_qp *qp, struct gdma_comp *cqe)
> +{
> +	u32 qtype = cqe->wq_num & MANA_QID_SUBTYPE_MASK;
> +
> +	if (qp->ibqp.qp_type != IB_QPT_RC)
> +		return cqe->is_sq;
> +
> +	return cqe->is_sq ? (qtype == MANA_QID_SUBTYPE_SREQ ||
> +			    qtype == MANA_QID_SUBTYPE_MMQ) :
> +			    qtype == MANA_QID_SUBTYPE_RREQ;

[Severity: High]
Does this logic invert the mapping for GDMA receive errors?

When cqe->is_sq is false, it returns true for Responder Requests (RREQ)
and false for Requester Responses (RRESP). Since RREQ consumes RECV WQEs and
RRESP consumes SEND WQEs, this seems to cause error completions to pop from
the wrong shadow queues.

Could this corrupt the shadow queues and user completions if a remote peer
sends a NAK or a packet drops, generating an error CQE on the GDMA receive
queue?

> +}
> +
> +static void mana_ib_schedule_qp_error(struct mana_ib_qp *qp)
> +{

[ ... ]

> @@ -521,6 +609,9 @@ static bool mana_handle_cqe(struct mana_ib_cq *cq, struct mana_ib_dev *mdev,
>  	case CQE_TYPE_LWR:
>  		consumed = handle_mmq_cqe(qp, rdma_cqe->rc_mm.fsn, poll);
>  		break;
> +	case CQE_TYPE_ERROR:
> +		consumed = handle_error_cqe(cq, qp, cqe, poll);

[Severity: High]
Will the QP lookup in mana_handle_cqe() successfully find the QP for RREQ
and RRESP error CQEs?

Earlier in mana_handle_cqe(), the QP is looked up via:

	struct mana_ib_qp *qp = mana_get_qp_ref(mdev, cqe->wq_num, cqe->is_sq);
	if (!qp)
		return true;

mana_get_qp_ref() searches for the base ID without MANA_SENDQ_MASK if
cqe->is_sq is false:

	qid &= ~MANA_QID_SUBTYPE_MASK;
	if (is_sq)
		qid |= MANA_SENDQ_MASK;
	qp = xa_load(&mdev->qp_table_wq, qid);

However, mana_table_store_qp() only inserts the SREQ (with MANA_SENDQ_MASK)
and Responder RQ (without the mask) into the QP table, omitting RREQ and
RRESP.

If the lookup fails, will this cause hardware error CQEs for the Requester
Receive Queue (RREQ) and Responder Send Queue (RRESP) to be silently dropped?
This appears to lead to leaked shadow WQEs and indefinitely hung RDMA clients
during READ/ATOMIC response errors.

> +		break;
>  	case CQE_TYPE_UD_SEND:
>  		if (cqe->is_sq) {
>  			handle_ud_sq_cqe(qp, rdma_cqe, poll);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261007153330.2979799-1-kotaranov@linux.microsoft.com?part=9