Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Eric Davis" <eric.davis@broadcom.com>
Cc: linux-rdma@vger.kernel.org
Subject: Re: [PATCH rdma-next 10/13] RDMA/core: queue pair attributes for unconnected transports
Date: Wed, 14 Oct 2026 22:41:39 +0000	[thread overview]
Message-ID: <sashiko-outbox-171988@kernel.org> (raw)
In-Reply-To: <20261014-uet-ib-core-v1-10-a0e626117113@broadcom.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] RDMA: missing IB_QPT_RU state machine validation in qp_state_table
--

commit e32578d06dac38500b6cb1196755de6b03c64308
Author: Eric Davis <eric.davis@broadcom.com>
Subject: RDMA/core: queue pair attributes for unconnected transports

This commit adds creation attributes for queue pairs on unconnected transports.
It introduces job keys to authorize actions, initiator identities, and
semantics checks for ordering guarantees.

> diff --git a/drivers/infiniband/core/uverbs_std_types_qp.c b/drivers/infiniband/core/uverbs_std_types_qp.c
> index c6225156fe30e..47ca994f9ac96 100644
> --- a/drivers/infiniband/core/uverbs_std_types_qp.c
> +++ b/drivers/infiniband/core/uverbs_std_types_qp.c
[ ... ]
> @@ -197,6 +331,7 @@ static int UVERBS_HANDLER(UVERBS_METHOD_QP_CREATE)(
>  	case IB_UVERBS_QPT_UC:
>  	case IB_UVERBS_QPT_UD:
>  	case IB_UVERBS_QPT_XRC_INI:
> +	case IB_UVERBS_QPT_RU:

[Severity: Medium]
Will this newly added transport fail state machine validation during creation?

When UVERBS_METHOD_QP_CREATE() creates an IB_QPT_RU QP, the core immediately
forces a transition from IB_QPS_RESET to IB_QPS_RTS via
ib_modify_qp_with_udata():

drivers/infiniband/core/uverbs_std_types_qp.c:
UVERBS_HANDLER(UVERBS_METHOD_QP_CREATE)() {
...
	if (attr.qp_type == IB_QPT_RU) {
		qp_attr.qp_state = IB_QPS_RTS;
		ret = ib_modify_qp_with_udata(qp, &qp_attr,
					      qp_attr_mask | IB_QP_STATE,
					      uverbs_get_cleared_udata(attrs));
...
}

However, IB_QPT_RU appears to be missing from the qp_state_table in
drivers/infiniband/core/verbs.c.

When a driver invokes ib_modify_qp_is_ok(), the missing table entries mean
the req_param and opt_param default to 0, and the transition is not marked
as valid. Doesn't this cause ib_modify_qp_is_ok() to unconditionally return
false and reject the QP modification for any driver attempting to support
this new transport?

>  	case IB_UVERBS_QPT_DRIVER:
>  		if (uverbs_attr_is_valid(attrs,
>  					 UVERBS_ATTR_CREATE_QP_XRCD_HANDLE) ||

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261014-uet-ib-core-v1-0-a0e626117113@broadcom.com?part=10

  reply	other threads:[~2026-10-14 22:41 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14 22:21 [PATCH rdma-next 00/13] RDMA/core: Ultra Ethernet transport verbs Eric Davis via B4 Relay
2026-10-14 22:21 ` [PATCH rdma-next 01/13] RDMA/core: widen the uverbs object key Eric Davis via B4 Relay
2026-10-14 22:29   ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 02/13] RDMA/core: add the UET GID types Eric Davis via B4 Relay
2026-10-14 22:35   ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 03/13] RDMA/core: report the reliable unconnected device capabilities Eric Davis via B4 Relay
2026-10-14 22:30   ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 04/13] RDMA/core: add the reliable unconnected queue pair type Eric Davis via B4 Relay
2026-10-14 22:43   ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 05/13] RDMA/core: extended address handle attributes Eric Davis via B4 Relay
2026-10-14 22:50   ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 06/13] RDMA/core: query the semantics a queue pair type guarantees Eric Davis via B4 Relay
2026-10-14 22:34   ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 07/13] RDMA/core: job and job key objects Eric Davis via B4 Relay
2026-10-14 22:36   ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 08/13] RDMA/uverbs: factor out the queue pair attribute copy Eric Davis via B4 Relay
2026-10-14 22:30   ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 09/13] RDMA/core: create a queue pair ready to send Eric Davis via B4 Relay
2026-10-14 22:39   ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 10/13] RDMA/core: queue pair attributes for unconnected transports Eric Davis via B4 Relay
2026-10-14 22:41   ` sashiko-bot [this message]
2026-10-14 22:21 ` [PATCH rdma-next 11/13] RDMA/core: extended memory registration Eric Davis via B4 Relay
2026-10-14 22:36   ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 12/13] RDMA/core: 64-bit memory keys Eric Davis via B4 Relay
2026-10-14 22:32   ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 13/13] RDMA/core: attach a memory region to a queue pair Eric Davis via B4 Relay
2026-10-14 22:37   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-171988@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=eric.davis@broadcom.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox