Re: [PATCH rdma-next v4 0/7] RDMA/bnxt_re: Support QP uapi extensions

[Jason Gunthorpe <jgg@ziepe.ca>]

On Fri, May 08, 2026 at 02:28:51PM +0530, Sriharsha Basavapatna wrote:

> Sriharsha Basavapatna (7):
>   RDMA/bnxt_re: Refactor bnxt_re_init_user_qp()
>   RDMA/bnxt_re: Update rq depth for app allocated QPs
>   RDMA/bnxt_re: Update sq depth for app allocated QPs
>   RDMA/bnxt_re: Update msn table size for app allocated QPs
>   RDMA/bnxt_re: Update hwq depth for app allocated QPs
>   RDMA/bnxt_re: Support doorbells for app allocated QPs
>   RDMA/bnxt_re: Enable app allocated QPs

There are alot of scary sashiko warnings, I stopped at this one:

https://sashiko.dev/#/patchset/20260508085858.21060-1-sriharsha.basavapatna%40broadcom.com

 If userspace passes 0 or 1 for req->sq_npsn, qplib_qp->msn_tbl_sz will
 evaluate to 0.
 When this QP is used, userspace could trigger the kernel's send path via
 ib_uverbs_post_send(), which calls bnxt_re_post_send() and ultimately
 bnxt_qplib_post_send().
 In bnxt_qplib_fill_msn_search(), there is a modulo calculation:
    qp->msn %= qp->msn_tbl_sz;
 Could this unvalidated req->sq_npsn lead to a divide-by-zero kernel panic?

Please go through them all. Fix the things newly added in this series,
especially the uapi issues like the above

It points out a bunch of pre-existing warnings too, please prepare a
seperate series to fix them, it can go after this one.

In future please be proactive to check sahsiko.dev don't wait for us
to look on it.

Jason