Re: [PATCH rdma-next v4 06/10] RDMA/mana_ib: Post send and memory-management WRs on RC QPs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] rdma/mana_ib: integer overflow in msg_sz causes silent data corruption
- [High] rdma/mana_ib: shadow queue stall due to leaked unsignaled MMQ WQEs
- [High] rdma: mana_ib: shadow queue leak on unsignaled fenced WQEs
--

commit b07a49d6904077b337ee7637a4f192e98b247c4a
Author: Konstantin Taranov <kotaranov@microsoft.com>
RDMA/mana_ib: Post send and memory-management WRs on RC QPs

This commit implements send work request posting for RC QPs. It posts
communication WRs to the send queue and memory WRs to the memory
management queue.

> diff --git a/drivers/infiniband/hw/mana/wr.c b/drivers/infiniband/hw/mana/wr.c
> index 5d42af91fce4a..6cc67537c6557 100644
> --- a/drivers/infiniband/hw/mana/wr.c
> +++ b/drivers/infiniband/hw/mana/wr.c
[ ... ]
> @@ -224,6 +289,287 @@ static int mana_ib_post_send_ud(struct mana_ib_qp *qp, const struct ib_send_wr *
>  	return err;
>  }
>  
> +static int mana_ib_post_sq(struct mana_ib_qp *qp, const struct ib_send_wr *wr)
> +{
[ ... ]
> +	u32 msg_sz = 0;
> +	int err, i;
> +
> +	if (shadow_queue_full(&qp->shadow_sq))
> +		return -ENOMEM;
> +
> +	if (wr->num_sge > MAX_TX_WQE_SGL_ENTRIES)
> +		return -EINVAL;
> +
> +	for (i = 0; i < wr->num_sge; i++)
> +		msg_sz += wr->sg_list[i].length;

[Severity: High]
Does this loop overflow msg_sz if a userspace application posts an RDMA
READ/WRITE or SEND WR with a total SGL length exceeding 4GB?

The IB core does not validate total SGL length, so drivers usually enforce
their own hardware limits.

[ ... ]
> +	switch (wr->opcode) {
> +	case IB_WR_SEND_WITH_INV:
[ ... ]
> +	case IB_WR_RDMA_WRITE_WITH_IMM:
> +		send_oob.immediate_ext = cpu_to_le32(be32_to_cpu(wr->ex.imm_data));
> +		fallthrough;
> +	case IB_WR_RDMA_WRITE:
> +	case IB_WR_RDMA_READ:
> +		send_oob.rdma.address_hi = upper_32_bits(rdma_wr(wr)->remote_addr);
> +		send_oob.rdma.address_low = lower_32_bits(rdma_wr(wr)->remote_addr);
> +		send_oob.rdma.rkey = rdma_wr(wr)->rkey;
> +		send_oob.rdma.dma_len = msg_sz;

If msg_sz overflows, would this instruct the hardware to silently truncate
the transfer while completing with success?

[ ... ]
> +	err = mana_gd_post_work_request(sq, &wqe_req, &wqe_info);
> +	if (err)
> +		return err;
> +
> +	shadow_wqe->wr_id = wr->wr_id;
> +	shadow_wqe->send_opcode = convert_wr_to_wc(wr->opcode);
> +	if (!signaled)
> +		shadow_wqe->flags |= MANA_WQ_NO_SIGNAL_WC;
> +	else if ((wr->send_flags & IB_SEND_FENCE) || qp->pending_mmq_fence)
> +		shadow_wqe->flags |= MANA_WQ_FENCE_WC;

[Severity: High]
Does the else if prevent an unsignaled work request from recording its
fence dependency in the shadow queue?

The RDMA verb API allows posting unsignaled WQEs that have fencing
requirements (either explicitly via IB_SEND_FENCE or implicitly via
pending_mmq_fence).

If MANA_WQ_FENCE_WC is missing on an unsignaled fenced WQE, it seems
the CQ polling logic won't evaluate the fence dependency. Could this leave
dependent WQEs leaked in the fixed-size shadow queue, eventually leading
to -ENOMEM failures?

> +	shadow_wqe->wqe_offset_or_psn = qp->sq_psn + mana_count_packets(msg_sz, qp->mtu);

Also related to the msg_sz overflow above, could the wrapped msg_sz
cause the software PSN to be advanced by a smaller amount than the hardware
transmits, desynchronizing the software PSN from the hardware PSN and
tearing down the QP?

[ ... ]
> +static int mana_ib_post_mmq(struct mana_ib_qp *qp, const struct ib_send_wr *wr)
> +{
[ ... ]
> +	shadow_wqe->wr_id = wr->wr_id;
> +	shadow_wqe->send_opcode = convert_wr_to_wc(wr->opcode);
> +	if (!signaled)
> +		shadow_wqe->flags |= MANA_WQ_NO_SIGNAL_WC;
> +	else if (wr->send_flags & IB_SEND_FENCE)
> +		shadow_wqe->flags |= MANA_WQ_FENCE_WC;

[Severity: High]
Does this else if block similarly prevent an unsignaled fenced WQE on
the MMQ from recording its fence dependency?

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