Re: [PATCH net-next v5] RDMA: Change capability fields in ib_device_attr from int to u32
Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/[email protected]> Tue, 2 Jun 2026 12:20:24 +0300
| Newsgroups | gmane.linux.nfs,gmane.linux.drivers.rdma,gmane.linux.kernel,gmane.linux.scsi.target.devel,gmane.linux.kernel.cifs,gmane.network.samba.internals,gmane.linux.network |
|---|---|
| Organization | Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo |
| Message-ID | <[email protected]> |
On Mon, Jun 01, 2026 at 02:14:44AM -0700, Erni Sri Satya Vennela 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. ... > attr->max_qp_rd_atom = > - min(1 << (fls(qattr->max_qp_resp_rd_atomic_resc) - 1), > - attr->max_qp_init_rd_atom); > + min_t(u32, 1 << (fls(qattr->max_qp_resp_rd_atomic_resc) - 1), > + attr->max_qp_init_rd_atom); Just no. min_t() usage has to be very well justified. It's a beast which may stub one in the back. As Linus said in most of the cases one wants clamp() rather than min(). Please, redo this and similar pieces. -- With Best Regards, Andy Shevchenko