Re: [PATCH 00/10] Provide udata helpers and use them in bnxt_re

Sriharsha Basavapatna
2026-02-06T12:20:23Z

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

On Fri, Feb 6, 2026 at 7:15 AM Jason Gunthorpe <jgg@nvidia.com> wrote:
>
> Add new helpers that entirely execute the expected common patterns for
> driver data uAPI forward and backwards compatibility so that drivers don't
> have to open code these.
>
> The helpers were developed by looking at the entire tree and moving every
> driver to use them, but this series only converts bnxt_re as it has a
> pending series to extend the driver data uAPI and the lack of correct
> compatibility handling will be problematic.
>
> This handles both the request and response side of the udata using the
> following general rules:
>
> 1) The userspace can provide a longer request so long as the trailing
> part the kernel doesn't understand is all zeros.
>
> This provides a degree of safety if the userspace wrongly tries to use
> a new feature the kernel does not understand with some non-zero value.
>
> It allows a simpler rdma-core implementation because the library can
> simply always use the latest structs for the request, even if they are
> bigger. It simply has to avoid using the new members if they are not
> supported/required.
>
> 2) The userspace can provide a shorter request, the kernel will 0 pad it
> out to fill the storage. The newer kernel should understand that older
> userspace will provide 0 to new fields. The kernel has three options
> to enable new request fields:
> - Input comp_mask that says the field is supported
> - Look for non-zero values
> - Check if the udata->inlen size covers the field
>
> This also corrects any bugs related to not filling in request
> structures as the new helper always fully writes to the struct.
>
> 3) The userspace can provide a shorter or longer response struct.
> If shorter the kernel reply is truncated. The kernel should be
> designed to not write to new reply field unless the userspace has
> affirmatively requested them.
>
> If the user buffer is longer then the kernel will zero fill it.
>
> Userspace has three options to enable new response fields:
> - Output comp_mask that says the field is supported
> - Look for non-zero values
> - Infer the output must be valid because the request contents demand
> it and old kernels will fail the request
>
> Since bnxt_re has never implemented these rules correctly and now does,
> provide a UCTX flag to tell userspace about it. If
> BNXT_RE_UCNTX_CMASK_UAPI_COMPAT_SUPPORTED is not set then userspace must
> not use any request or response fields beyond the current kernel uAPI.
>
> Using any new fields is only possible on kernels with the flag.
>
> A series converting all drivers to these new helpers is on github, I will
> send it later:
>
> https://github.com/jgunthorpe/linux/commits/rdma_uapi/
>
> Jason Gunthorpe (10):
> RDMA: Add ib_copy_validate_udata_in()
> RDMA: Add ib_copy_validate_udata_in_cm()
> RDMA: Add ib_respond_udata()
> RDMA: Add ib_is_udata_in_empty()
> RDMA: Provide documentation about the uABI compatibility rules
> RDMA/bnxt_re: Add compatibility checks to the uapi path
> RDMA/bnxt_re: Add compatibility checks to the uapi path for no data
> RDMA/bnxt_re: Add missing comp_mask validation
> RDMA/bnxt_re: Use ib_respond_udata()
> RDMA/bnxt_re: Add BNXT_RE_UCNTX_CMASK_UAPI_COMPAT_SUPPORTED
>
> drivers/infiniband/hw/bnxt_re/ib_verbs.c | 84 +++++++---
> include/rdma/ib_verbs.h | 185 +++++++++++++++++++++++
> include/uapi/rdma/bnxt_re-abi.h | 1 +
> 3 files changed, 251 insertions(+), 19 deletions(-)
>
>
> base-commit: aace79adb7196a02ff45a334839a4d31a0e262fb
> --
> 2.43.0
>

Thanks for this patch series. Patches 6, 7, 8 and 10 failed to apply
cleanly, due to conflicts with the recently merged QP rate limit
patchset in bnxt_re. So please rebase it.
I applied this series, + QP-dmabuf devop patch, + bnxt_re DV series
and tested it. It worked fine.

For the series:
Acked-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Tested-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>

Thanks,
-Harsha

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