[PATCH rdma-next 0/2] RDMA: Small batch of cleanups

[PATCH rdma-next 0/2] RDMA: Small batch of cleanups

[Leon Romanovsky]

This series contains two independent cleanups. One fixes the problematic placemen
 of a newly introduced in-kernel API, which should be called at the beginning of
destroy functions and not at the end. The other removes a redundant memset().

Thanks.

Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
Leon Romanovsky (2):
      RDMA/bnxt_re: Validate udata before destroying resources
      RDMA: Remove redundant memset() from query_device callbacks

 drivers/infiniband/hw/bnxt_re/ib_verbs.c     | 21 ++++++++++-----------
 drivers/infiniband/hw/efa/efa_verbs.c        |  1 -
 drivers/infiniband/hw/erdma/erdma_verbs.c    |  2 --
 drivers/infiniband/hw/hns/hns_roce_main.c    |  2 --
 drivers/infiniband/hw/irdma/verbs.c          |  1 -
 drivers/infiniband/hw/mana/main.c            |  1 -
 drivers/infiniband/hw/mlx4/main.c            |  2 --
 drivers/infiniband/hw/mlx5/main.c            |  1 -
 drivers/infiniband/hw/mthca/mthca_provider.c |  2 --
 drivers/infiniband/hw/ocrdma/ocrdma_verbs.c  |  1 -
 drivers/infiniband/hw/qedr/verbs.c           |  2 --
 drivers/infiniband/hw/usnic/usnic_ib_verbs.c |  1 -
 drivers/infiniband/sw/siw/siw_verbs.c        |  2 --
 13 files changed, 10 insertions(+), 29 deletions(-)
---
base-commit: 15ae32c4a3551c4c9da457370bdfdd65d171e512
change-id: 20260712-fix-destroy-no-udata-dfa990b985ea

Best regards,
--  
Leon Romanovsky <leonro@nvidia.com>

[PATCH rdma-next 1/2] RDMA/bnxt_re: Validate udata before destroying resources

[Leon Romanovsky]

From: Leon Romanovsky <leonro@nvidia.com>

The destroy callbacks currently zero the udata output after tearing down
their resources. If that userspace access fails, uverbs preserves the
uobject and permits the destroy callback to be entered again even though
the driver resource has already been released.

Use ib_no_udata_io() before teardown so all udata failures occur while the
resource is still intact, then return success after teardown completes.

Fixes: bed686d8dcd4 ("RDMA/bnxt_re: Use ib_respond_empty_udata()")
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
 drivers/infiniband/hw/bnxt_re/ib_verbs.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/infiniband/hw/bnxt_re/ib_verbs.c b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
index 565762529007..ef9943be1886 100644
--- a/drivers/infiniband/hw/bnxt_re/ib_verbs.c
+++ b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
@@ -695,7 +695,7 @@ int bnxt_re_dealloc_pd(struct ib_pd *ib_pd, struct ib_udata *udata)
 	struct bnxt_re_dev *rdev = pd->rdev;
 	int ret;
 
-	ret = ib_is_udata_in_empty(udata);
+	ret = ib_no_udata_io(udata);
 	if (ret)
 		return ret;
 
@@ -712,7 +712,7 @@ int bnxt_re_dealloc_pd(struct ib_pd *ib_pd, struct ib_udata *udata)
 					   &pd->qplib_pd))
 			atomic_dec(&rdev->stats.res.pd_count);
 	}
-	return ib_respond_empty_udata(udata);
+	return 0;
 }
 
 int bnxt_re_alloc_pd(struct ib_pd *ibpd, struct ib_udata *udata)
@@ -1015,7 +1015,7 @@ int bnxt_re_destroy_qp(struct ib_qp *ib_qp, struct ib_udata *udata)
 	unsigned int flags;
 	int rc;
 
-	rc = ib_is_udata_in_empty(udata);
+	rc = ib_no_udata_io(udata);
 	if (rc)
 		return rc;
 
@@ -1064,7 +1064,7 @@ int bnxt_re_destroy_qp(struct ib_qp *ib_qp, struct ib_udata *udata)
 	if (scq_nq != rcq_nq)
 		bnxt_re_synchronize_nq(rcq_nq);
 
-	return ib_respond_empty_udata(udata);
+	return 0;
 }
 
 static u8 __from_ib_qp_type(enum ib_qp_type type)
@@ -2148,7 +2148,7 @@ int bnxt_re_destroy_srq(struct ib_srq *ib_srq, struct ib_udata *udata)
 	struct bnxt_qplib_srq *qplib_srq = &srq->qplib_srq;
 	int ret;
 
-	ret = ib_is_udata_in_empty(udata);
+	ret = ib_no_udata_io(udata);
 	if (ret)
 		return ret;
 
@@ -2159,7 +2159,7 @@ int bnxt_re_destroy_srq(struct ib_srq *ib_srq, struct ib_udata *udata)
 		free_page((unsigned long)srq->uctx_srq_page);
 	ib_umem_release(srq->umem);
 	atomic_dec(&rdev->stats.res.srq_count);
-	return ib_respond_empty_udata(udata);
+	return 0;
 }
 
 static int bnxt_re_init_user_srq(struct bnxt_re_dev *rdev,
@@ -3471,7 +3471,7 @@ int bnxt_re_destroy_cq(struct ib_cq *ib_cq, struct ib_udata *udata)
 	nq = cq->qplib_cq.nq;
 	cctx = rdev->chip_ctx;
 
-	ret = ib_is_udata_in_empty(udata);
+	ret = ib_no_udata_io(udata);
 	if (ret)
 		return ret;
 
@@ -3486,7 +3486,7 @@ int bnxt_re_destroy_cq(struct ib_cq *ib_cq, struct ib_udata *udata)
 	atomic_dec(&rdev->stats.res.cq_count);
 	kfree(cq->cql);
 	ib_umem_release(cq->umem);
-	return ib_respond_empty_udata(udata);
+	return 0;
 }
 
 int bnxt_re_create_user_cq(struct ib_cq *ibcq, const struct ib_cq_init_attr *attr,
@@ -4449,7 +4449,7 @@ int bnxt_re_dereg_mr(struct ib_mr *ib_mr, struct ib_udata *udata)
 	struct bnxt_re_dev *rdev = mr->rdev;
 	int rc;
 
-	rc = ib_is_udata_in_empty(udata);
+	rc = ib_no_udata_io(udata);
 	if (rc)
 		return rc;
 
@@ -4472,7 +4472,7 @@ int bnxt_re_dereg_mr(struct ib_mr *ib_mr, struct ib_udata *udata)
 	atomic_dec(&rdev->stats.res.mr_count);
 	if (rc)
 		return rc;
-	return ib_respond_empty_udata(udata);
+	return 0;
 }
 
 static int bnxt_re_set_page(struct ib_mr *ib_mr, u64 addr)

-- 
2.54.0

Re: [PATCH rdma-next 1/2] RDMA/bnxt_re: Validate udata before destroying resources

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Missing hash_del on error paths in CQ and SRQ creation leads to hash table corruption and use-after-free.
- [Critical] Lockless modifications and iterations over device-global hash tables (cq_hash and srq_hash) risk linked-list corruption.
- [High] Hardware Address Handle (AH) resource leak in bnxt_re_create_ah on udata response failure.
- [High] Hardware and driver state modification applied before udata validation in modify/resize callbacks.
- [High] Memory leak of rdma_user_mmap_entry in bnxt_re_alloc_ucontext if udata validation or response fails.
--

--- Patch [1]: [PATCH rdma-next 1/2] RDMA/bnxt_re: Validate udata before destroying resources ---
commit 1661d6c7bf0fdc123a46584fd78311e626482940
Author: Leon Romanovsky <leon@kernel.org>

RDMA/bnxt_re: Validate udata before destroying resources

This commit modifies the destroy callbacks to validate user data earlier
using ib_no_udata_io() before resources are torn down. This prevents
userspace access failures from leaving the driver and hardware in an
inconsistent state.

> diff --git a/drivers/infiniband/hw/bnxt_re/ib_verbs.c b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> index 5657625290076..ef9943be18861 100644
> --- a/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> +++ b/drivers/infiniband/hw/bnxt_re/ib_verbs.c

[ ... ]

> @@ -3471,7 +3471,7 @@ int bnxt_re_destroy_cq(struct ib_cq *ib_cq, struct ib_udata *udata)
>  	nq = cq->qplib_cq.nq;
>  	cctx = rdev->chip_ctx;
>  
> -	ret = ib_is_udata_in_empty(udata);
> +	ret = ib_no_udata_io(udata);
>  	if (ret)
>  		return ret;

[Severity: Critical]
This is a pre-existing issue, but does removing the CQ from the global hash
table here require locking?

In bnxt_re_destroy_cq(), just after this udata validation, the CQ is deleted
from rdev->cq_hash via hash_del() without any locks:

    if (cctx->modes.toggle_bits & BNXT_QPLIB_CQ_TOGGLE_BIT)
        hash_del(&cq->hash_entry);

However, concurrent additions occur in bnxt_re_create_user_cq() via
hash_add() and lockless iterations happen in bnxt_re_search_for_cq(). Can
this cause list corruption or use-after-free if multiple threads create,
destroy, or query CQs concurrently?

[Severity: Critical]
This isn't a bug introduced by this patch, but can this leak a dangling
pointer into the hash table on error?

In bnxt_re_create_user_cq(), if memory allocation for the page fails or
ib_respond_udata() fails, we jump to the error path and free the CQ without
removing it from the hash table:

bnxt_re_create_user_cq() {
    ...
    if (cctx->modes.toggle_bits & BNXT_QPLIB_CQ_TOGGLE_BIT) {
        hash_add(rdev->cq_hash, &cq->hash_entry, cq->qplib_cq.id);
        /* Allocate a page */
        cq->uctx_cq_page = (void *)get_zeroed_page(GFP_KERNEL);
        if (!cq->uctx_cq_page) {
            rc = -ENOMEM;
            goto destroy_cq;
        }
    ...
    rc = ib_respond_udata(udata, resp);
    if (rc)
        goto free_mem;
    ...
free_mem:
    free_page((unsigned long)cq->uctx_cq_page);
destroy_cq:
    bnxt_qplib_destroy_cq(&rdev->qplib_res, &cq->qplib_cq);
free_umem:
    ib_umem_release(cq->umem);
    return rc;
}

Since hash_del() isn't called here, could subsequent lookups hit a
use-after-free? This same pattern also appears in bnxt_re_create_srq()
where srq_hash is modified.

[Severity: High]
This isn't a bug introduced by this patch, but since this patch fixes udata
validation in destroy callbacks, should similar fixes be applied to the
modify and resize callbacks?

In functions like bnxt_re_modify_srq(), bnxt_re_modify_qp(), and
bnxt_re_resize_cq(), the hardware and driver state is modified before the
final copy-to-user response:

drivers/infiniband/hw/bnxt_re/ib_verbs.c:bnxt_re_modify_qp() {
    ...
    /* hardware QP state is modified here */
    ...
    return ib_respond_empty_udata(udata);
}

If the udata response buffer is invalid, the function fails, but the hardware
and driver states are already updated. Can this desynchronize kernel state
from userspace state?

[Severity: High]
This is a pre-existing issue, but does this error path permanently leak the
hardware Address Handle?

If ib_respond_empty_udata() fails in bnxt_re_create_ah(), the function
returns the error directly without cleaning up the hardware AH or
decrementing ah_count:

drivers/infiniband/hw/bnxt_re/ib_verbs.c:bnxt_re_create_ah() {
    ...
    return ib_respond_empty_udata(udata);
}

Can an unprivileged application repeatedly trigger this by passing an invalid
udata response buffer to exhaust hardware resources and kernel memory?

[Severity: High]
This is a pre-existing issue, but does the cfail error path leak the mmap
entry?

In bnxt_re_alloc_ucontext(), if validation or the udata response fails, we
jump to cfail:

drivers/infiniband/hw/bnxt_re/ib_verbs.c:bnxt_re_alloc_ucontext() {
    ...
    rc = ib_respond_udata(udata, resp);
    if (rc) {
        rc = -EFAULT;
        goto cfail;
    }
    ...
cfail:
    free_page((unsigned long)uctx->shpg);
    uctx->shpg = NULL;
fail:
    return rc;
}

This path skips calling rdma_user_mmap_entry_remove(uctx->shpage_mmap).
Does this permanently leak the kzalloc'd mmap entry, allowing memory
exhaustion if triggered repeatedly by userspace?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260713-fix-destroy-no-udata-v1-0-fcca2e34fd57@nvidia.com?part=1

Re: [PATCH rdma-next 1/2] RDMA/bnxt_re: Validate udata before destroying resources

[Jacob Moroni]

These changes look good but there is also a call to ib_respond_empty_udata
in bnxt_re_resize_cq (but that method does take input data).

Is that one a problem? I guess the resize could complete but the upper
layers would think it failed if the ib_respond_empty_udata call fails?

Reviewed-by: Jacob Moroni <jmoroni@google.com>

Re: [PATCH rdma-next 1/2] RDMA/bnxt_re: Validate udata before destroying resources

[Leon Romanovsky]

On Mon, Jul 13, 2026 at 10:21:49AM -0400, Jacob Moroni wrote:
> These changes look good but there is also a call to ib_respond_empty_udata
> in bnxt_re_resize_cq (but that method does take input data).
> 
> Is that one a problem? I guess the resize could complete but the upper
> layers would think it failed if the ib_respond_empty_udata call fails?

I think that modify verbs should be fixed too.

> 
> Reviewed-by: Jacob Moroni <jmoroni@google.com>

Thanks

Re: [PATCH rdma-next 1/2] RDMA/bnxt_re: Validate udata before destroying resources

[Selvin Xavier]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

On Mon, Jul 13, 2026 at 8:26 PM Leon Romanovsky <leon@kernel.org> wrote:
>
> On Mon, Jul 13, 2026 at 10:21:49AM -0400, Jacob Moroni wrote:
> > These changes look good but there is also a call to ib_respond_empty_udata
> > in bnxt_re_resize_cq (but that method does take input data).
> >
> > Is that one a problem? I guess the resize could complete but the upper
> > layers would think it failed if the ib_respond_empty_udata call fails?
>
> I think that modify verbs should be fixed too.
>
> >
> > Reviewed-by: Jacob Moroni <jmoroni@google.com>
Acked-by: Selvin Xavier <selvin.xavier@broadcom.com>
Thanks
>
> Thanks

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5473 bytes --]

[PATCH rdma-next 2/2] RDMA: Remove redundant memset() from query_device callbacks

[Leon Romanovsky]

From: Leon Romanovsky <leonro@nvidia.com>

The core always hands the driver's query_device() callback a zeroed
ib_device_attr. There are only two callers of the op and both clear the
structure before invoking it: setup_device() memsets &device->attrs, and
ib_uverbs_ex_query_device() passes an on-stack structure initialized to {}.

The open-coded memset(props, 0, sizeof(*props)) at the top of the driver
callbacks is therefore redundant. Remove it from all drivers.

Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
 drivers/infiniband/hw/bnxt_re/ib_verbs.c     | 1 -
 drivers/infiniband/hw/efa/efa_verbs.c        | 1 -
 drivers/infiniband/hw/erdma/erdma_verbs.c    | 2 --
 drivers/infiniband/hw/hns/hns_roce_main.c    | 2 --
 drivers/infiniband/hw/irdma/verbs.c          | 1 -
 drivers/infiniband/hw/mana/main.c            | 1 -
 drivers/infiniband/hw/mlx4/main.c            | 2 --
 drivers/infiniband/hw/mlx5/main.c            | 1 -
 drivers/infiniband/hw/mthca/mthca_provider.c | 2 --
 drivers/infiniband/hw/ocrdma/ocrdma_verbs.c  | 1 -
 drivers/infiniband/hw/qedr/verbs.c           | 2 --
 drivers/infiniband/hw/usnic/usnic_ib_verbs.c | 1 -
 drivers/infiniband/sw/siw/siw_verbs.c        | 2 --
 13 files changed, 19 deletions(-)

diff --git a/drivers/infiniband/hw/bnxt_re/ib_verbs.c b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
index ef9943be1886..1f32537dc528 100644
--- a/drivers/infiniband/hw/bnxt_re/ib_verbs.c
+++ b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
@@ -193,7 +193,6 @@ int bnxt_re_query_device(struct ib_device *ibdev,
 	if (rc)
 		return rc;
 
-	memset(ib_attr, 0, sizeof(*ib_attr));
 	memcpy(&ib_attr->fw_ver, dev_attr->fw_ver,
 	       min(sizeof(dev_attr->fw_ver),
 		   sizeof(ib_attr->fw_ver)));
diff --git a/drivers/infiniband/hw/efa/efa_verbs.c b/drivers/infiniband/hw/efa/efa_verbs.c
index ec124fbda637..6be8ec53dcb3 100644
--- a/drivers/infiniband/hw/efa/efa_verbs.c
+++ b/drivers/infiniband/hw/efa/efa_verbs.c
@@ -222,7 +222,6 @@ int efa_query_device(struct ib_device *ibdev,
 
 	dev_attr = &dev->dev_attr;
 
-	memset(props, 0, sizeof(*props));
 	props->max_mr_size = dev_attr->max_mr_pages * PAGE_SIZE;
 	props->page_size_cap = dev_attr->page_size_cap;
 	props->vendor_id = dev->pdev->vendor;
diff --git a/drivers/infiniband/hw/erdma/erdma_verbs.c b/drivers/infiniband/hw/erdma/erdma_verbs.c
index 74afe6eb18b0..9491cbab69b3 100644
--- a/drivers/infiniband/hw/erdma/erdma_verbs.c
+++ b/drivers/infiniband/hw/erdma/erdma_verbs.c
@@ -324,8 +324,6 @@ int erdma_query_device(struct ib_device *ibdev, struct ib_device_attr *attr,
 	if (err)
 		return err;
 
-	memset(attr, 0, sizeof(*attr));
-
 	attr->max_mr_size = dev->attrs.max_mr_size;
 	attr->vendor_id = PCI_VENDOR_ID_ALIBABA;
 	attr->vendor_part_id = dev->pdev->device;
diff --git a/drivers/infiniband/hw/hns/hns_roce_main.c b/drivers/infiniband/hw/hns/hns_roce_main.c
index c6f633bd5a34..09c07de5f022 100644
--- a/drivers/infiniband/hw/hns/hns_roce_main.c
+++ b/drivers/infiniband/hw/hns/hns_roce_main.c
@@ -227,8 +227,6 @@ static int hns_roce_query_device(struct ib_device *ib_dev,
 	if (ret)
 		return ret;
 
-	memset(props, 0, sizeof(*props));
-
 	props->fw_ver = hr_dev->caps.fw_ver;
 	props->sys_image_guid = cpu_to_be64(hr_dev->sys_image_guid);
 	props->max_mr_size = (u64)(~(0ULL));
diff --git a/drivers/infiniband/hw/irdma/verbs.c b/drivers/infiniband/hw/irdma/verbs.c
index 5c907ffce99b..c9b606cc67d4 100644
--- a/drivers/infiniband/hw/irdma/verbs.c
+++ b/drivers/infiniband/hw/irdma/verbs.c
@@ -22,7 +22,6 @@ static int irdma_query_device(struct ib_device *ibdev,
 	if (err)
 		return err;
 
-	memset(props, 0, sizeof(*props));
 	addrconf_addr_eui48((u8 *)&props->sys_image_guid,
 			    iwdev->netdev->dev_addr);
 	props->fw_ver = (u64)irdma_fw_major_ver(&rf->sc_dev) << 32 |
diff --git a/drivers/infiniband/hw/mana/main.c b/drivers/infiniband/hw/mana/main.c
index efe2935bda29..a5b3606a1dd5 100644
--- a/drivers/infiniband/hw/mana/main.c
+++ b/drivers/infiniband/hw/mana/main.c
@@ -579,7 +579,6 @@ int mana_ib_query_device(struct ib_device *ibdev, struct ib_device_attr *props,
 	if (err)
 		return err;
 
-	memset(props, 0, sizeof(*props));
 	props->vendor_id = pdev->vendor;
 	props->vendor_part_id = dev->gdma_dev->dev_id.type;
 	props->max_mr_size = MANA_IB_MAX_MR_SIZE;
diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c
index 17073e8f105a..7266a6141944 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -471,8 +471,6 @@ static int mlx4_ib_query_device(struct ib_device *ibdev,
 	if (err)
 		goto out;
 
-	memset(props, 0, sizeof *props);
-
 	have_ib_ports = num_ib_ports(dev->dev);
 
 	props->fw_ver = dev->dev->caps.fw_ver;
diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
index 02809114fc79..e8bba5a76d4e 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -969,7 +969,6 @@ static int mlx5_ib_query_device(struct ib_device *ibdev,
 	if (err)
 		return err;
 
-	memset(props, 0, sizeof(*props));
 	err = mlx5_query_system_image_guid(ibdev,
 					   &props->sys_image_guid);
 	if (err)
diff --git a/drivers/infiniband/hw/mthca/mthca_provider.c b/drivers/infiniband/hw/mthca/mthca_provider.c
index f90f67afc8fa..e933a53779a4 100644
--- a/drivers/infiniband/hw/mthca/mthca_provider.c
+++ b/drivers/infiniband/hw/mthca/mthca_provider.c
@@ -69,8 +69,6 @@ static int mthca_query_device(struct ib_device *ibdev, struct ib_device_attr *pr
 		goto out;
 	}
 
-	memset(props, 0, sizeof *props);
-
 	props->fw_ver              = mdev->fw_ver;
 
 	ib_init_query_mad(in_mad);
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
index 53ba32d168a1..de83dc0ea79c 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
@@ -74,7 +74,6 @@ int ocrdma_query_device(struct ib_device *ibdev, struct ib_device_attr *attr,
 	if (err)
 		return err;
 
-	memset(attr, 0, sizeof *attr);
 	memcpy(&attr->fw_ver, &dev->attr.fw_ver[0],
 	       min(sizeof(dev->attr.fw_ver), sizeof(attr->fw_ver)));
 	addrconf_addr_eui48((u8 *)&attr->sys_image_guid,
diff --git a/drivers/infiniband/hw/qedr/verbs.c b/drivers/infiniband/hw/qedr/verbs.c
index d5416b161340..1cf502579ad1 100644
--- a/drivers/infiniband/hw/qedr/verbs.c
+++ b/drivers/infiniband/hw/qedr/verbs.c
@@ -118,8 +118,6 @@ int qedr_query_device(struct ib_device *ibdev,
 	if (rc)
 		return rc;
 
-	memset(attr, 0, sizeof(*attr));
-
 	attr->fw_ver = qattr->fw_ver;
 	attr->sys_image_guid = qattr->sys_image_guid;
 	attr->max_mr_size = qattr->max_mr_size;
diff --git a/drivers/infiniband/hw/usnic/usnic_ib_verbs.c b/drivers/infiniband/hw/usnic/usnic_ib_verbs.c
index dc355b00f61c..3402c84eb904 100644
--- a/drivers/infiniband/hw/usnic/usnic_ib_verbs.c
+++ b/drivers/infiniband/hw/usnic/usnic_ib_verbs.c
@@ -284,7 +284,6 @@ int usnic_ib_query_device(struct ib_device *ibdev,
 
 	mutex_lock(&us_ibdev->usdev_lock);
 	us_ibdev->netdev->ethtool_ops->get_drvinfo(us_ibdev->netdev, &info);
-	memset(props, 0, sizeof(*props));
 	usnic_mac_ip_to_gid(us_ibdev->ufdev->mac, us_ibdev->ufdev->inaddr,
 			&gid.raw[0]);
 	memcpy(&props->sys_image_guid, &gid.global.interface_id,
diff --git a/drivers/infiniband/sw/siw/siw_verbs.c b/drivers/infiniband/sw/siw/siw_verbs.c
index b74ac85c1b8b..e281517fc6f9 100644
--- a/drivers/infiniband/sw/siw/siw_verbs.c
+++ b/drivers/infiniband/sw/siw/siw_verbs.c
@@ -136,8 +136,6 @@ int siw_query_device(struct ib_device *base_dev, struct ib_device_attr *attr,
 	if (rv)
 		return rv;
 
-	memset(attr, 0, sizeof(*attr));
-
 	/* Revisit atomic caps if RFC 7306 gets supported */
 	attr->atomic_cap = 0;
 	attr->device_cap_flags = IB_DEVICE_MEM_MGT_EXTENSIONS;

-- 
2.54.0

Re: (subset) [PATCH rdma-next 0/2] RDMA: Small batch of cleanups

[Leon Romanovsky]

On Mon, 13 Jul 2026 11:10:33 +0300, Leon Romanovsky wrote:
> This series contains two independent cleanups. One fixes the problematic placemen
>  of a newly introduced in-kernel API, which should be called at the beginning of
> destroy functions and not at the end. The other removes a redundant memset().
> 
> Thanks.
> 
> 
> [...]

Applied, thanks!

[2/2] RDMA: Remove redundant memset() from query_device callbacks
      https://git.kernel.org/rdma/rdma/c/eeb9697db6c16d

Best regards,
-- 
Leon Romanovsky <leon@kernel.org>

Re: [PATCH rdma-next 0/2] RDMA: Small batch of cleanups

[Leon Romanovsky]

On Mon, Jul 13, 2026 at 11:10:33AM +0300, Leon Romanovsky wrote:
> This series contains two independent cleanups. One fixes the problematic placemen
>  of a newly introduced in-kernel API, which should be called at the beginning of
> destroy functions and not at the end. The other removes a redundant memset().
> 
> Thanks.
> 
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> ---
> Leon Romanovsky (2):
>       RDMA/bnxt_re: Validate udata before destroying resources

I'll resend this one.

>       RDMA: Remove redundant memset() from query_device callbacks

And applied this.