From: David Laight <david.laight.linux@gmail.com>
To: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
Cc: mkalderon@marvell.com, Jason Gunthorpe <jgg@ziepe.ca>,
Leon Romanovsky <leon@kernel.org>,
zyjzyj2000@gmail.com, sagi@grimberg.me, mgurtovoy@nvidia.com,
haris.iqbal@ionos.com, jinpu.wang@ionos.com, bvanassche@acm.org,
kbusch@kernel.org, Jens Axboe <axboe@kernel.dk>,
Christoph Hellwig <hch@lst.de>,
kch@nvidia.com, smfrench@gmail.com, linkinjeon@kernel.org,
metze@samba.org, tom@talpey.com, chuck.lever@oracle.com,
jlayton@kernel.org, neil@brown.name, okorniev@redhat.com,
Dai.Ngo@oracle.com, trondmy@kernel.org, anna@kernel.org,
achender@kernel.org, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
kees@kernel.org, andriy.shevchenko@linux.intel.com,
ebadger@purestorage.com, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org, target-devel@vger.kernel.org,
linux-nvme@lists.infradead.org, linux-cifs@vger.kernel.org,
samba-technical@lists.samba.org, linux-nfs@vger.kernel.org,
netdev@vger.kernel.org, rds-devel@oss.oracle.com,
Jason Gunthorpe <jgg@nvidia.com>
Subject: Re: [PATCH rdma-next v6] RDMA: Change capability fields in ib_device_attr from int to u32
Date: Tue, 2 Jun 2026 12:33:27 +0100 [thread overview]
Message-ID: <20260602123327.35aa286a@pumpkin> (raw)
In-Reply-To: <20260601092534.1764560-1-ernis@linux.microsoft.com>
On Mon, 1 Jun 2026 02:25:15 -0700
Erni Sri Satya Vennela <ernis@linux.microsoft.com> wrote:
> The capability counter fields in struct ib_device_attr are declared
> as signed int, but these values are inherently non-negative. Drivers
> maintain their cached caps as u32 and assign them directly into these
> int fields; if a cap exceeds INT_MAX the implicit narrowing yields a
> negative value visible to the IB core.
>
> Change the signed int capability fields to u32 to match the
> underlying nature of the data. Also update consumers across the IB
> core, ULPs, NVMe-oF target, RDS, and NFS/RDMA so the new u32 values
> are not forced back through signed int or u8 via min()/min_t() or
> narrowing local variables.
>
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
> ---
...
> diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv.c b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
> index 6482ad859bd1..852213365ecd 100644
> --- a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
> +++ b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
> @@ -1731,7 +1731,7 @@ static int create_con(struct rtrs_srv_path *srv_path,
> * All receive and all send (each requiring invalidate)
> * + 2 for drain and heartbeat
> */
> - max_send_wr = min_t(int, wr_limit,
> + max_send_wr = min_t(u32, wr_limit,
> SERVICE_CON_QUEUE_DEPTH * 2 + 2);
That should compile as min().
(The constant is known to be non-negative.)
...
> diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
> index e6e2c3f9afdf..fd6923198ec1 100644
> --- a/drivers/nvme/target/rdma.c
> +++ b/drivers/nvme/target/rdma.c
...
> @@ -1553,8 +1554,8 @@ static int nvmet_rdma_cm_accept(struct rdma_cm_id *cm_id,
>
> param.rnr_retry_count = 7;
> param.flow_control = 1;
> - param.initiator_depth = min_t(u8, p->initiator_depth,
> - queue->dev->device->attrs.max_qp_init_rd_atom);
> + param.initiator_depth = (u8)min_t(u32, p->initiator_depth,
> + min_t(u32, U8_MAX, queue->dev->device->attrs.max_qp_init_rd_atom));
I think you've change one of those to min_3().
Nesting min() is a good way to bloat the pre-processor output.
You don't need any of the casts.
param.initiator_depth = min_3(p->initiator_depth,
queue->dev->device->attrs.max_qp_init_rd_atom, U8_MAX);
should be fine - if a bit long.
There are also (u32)U8_MAX casts lurking - pointless.
-- David
next prev parent reply other threads:[~2026-06-02 11:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-01 9:25 [PATCH rdma-next v6] RDMA: Change capability fields in ib_device_attr from int to u32 Erni Sri Satya Vennela
2026-06-01 15:51 ` Bart Van Assche
2026-06-02 9:21 ` Andy Shevchenko
2026-06-02 11:21 ` David Laight
2026-06-06 6:59 ` Erni Sri Satya Vennela
2026-06-06 6:50 ` Erni Sri Satya Vennela
2026-06-06 6:48 ` Erni Sri Satya Vennela
2026-06-02 11:33 ` David Laight [this message]
2026-06-06 7:01 ` Erni Sri Satya Vennela
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=20260602123327.35aa286a@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=Dai.Ngo@oracle.com \
--cc=achender@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=anna@kernel.org \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=chuck.lever@oracle.com \
--cc=davem@davemloft.net \
--cc=ebadger@purestorage.com \
--cc=edumazet@google.com \
--cc=ernis@linux.microsoft.com \
--cc=haris.iqbal@ionos.com \
--cc=hch@lst.de \
--cc=horms@kernel.org \
--cc=jgg@nvidia.com \
--cc=jgg@ziepe.ca \
--cc=jinpu.wang@ionos.com \
--cc=jlayton@kernel.org \
--cc=kbusch@kernel.org \
--cc=kch@nvidia.com \
--cc=kees@kernel.org \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linkinjeon@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-rdma@vger.kernel.org \
--cc=metze@samba.org \
--cc=mgurtovoy@nvidia.com \
--cc=mkalderon@marvell.com \
--cc=neil@brown.name \
--cc=netdev@vger.kernel.org \
--cc=okorniev@redhat.com \
--cc=pabeni@redhat.com \
--cc=rds-devel@oss.oracle.com \
--cc=sagi@grimberg.me \
--cc=samba-technical@lists.samba.org \
--cc=smfrench@gmail.com \
--cc=target-devel@vger.kernel.org \
--cc=tom@talpey.com \
--cc=trondmy@kernel.org \
--cc=zyjzyj2000@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.