[PATCH rdma-next] RDMA/mana_ib: Retain create CQ flags field name

[PATCH rdma-next] RDMA/mana_ib: Retain create CQ flags field name

[Jiri Pirko]

From: Jiri Pirko <jiri@nvidia.com>

Commit eb70d83a8645 ("RDMA/mana_ib: Adopt robust udata") renamed the
"flags" field of struct mana_ib_create_cq to "comp_mask", as
ib_copy_validate_udata_in_cm() only validates a member with that name.

The layout did not change, but the field has been a part of the UAPI
since commit 44b607ad4cdf ("RDMA/mana_ib: implement uapi for creation
of rnic cq"), so the rename breaks userspace referring to it,
for example the mana provider of rdma-core assigning cmd_drv->flags.

Convert the field to a union providing both names, so that
ib_copy_validate_udata_in_cm() still finds "comp_mask" and userspace
keeps "flags", without having to add a helper for this single case.

Fixes: eb70d83a8645 ("RDMA/mana_ib: Adopt robust udata")
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
---
 include/uapi/rdma/mana-abi.h | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/uapi/rdma/mana-abi.h b/include/uapi/rdma/mana-abi.h
index 410f0ddc8c89..431c7076f20a 100644
--- a/include/uapi/rdma/mana-abi.h
+++ b/include/uapi/rdma/mana-abi.h
@@ -25,7 +25,10 @@ enum mana_ib_create_cq_flags {
 
 struct mana_ib_create_cq {
 	__aligned_u64 buf_addr;
-	__u16	comp_mask;
+	union {
+		__u16	comp_mask;
+		__u16	flags; /* the original name of the field */
+	};
 	__u16	reserved0;
 	__u32	reserved1;
 };
-- 
2.54.0

RE: [PATCH rdma-next] RDMA/mana_ib: Retain create CQ flags field name

[Konstantin Taranov]

> From: Jiri Pirko <jiri@nvidia.com>
> 
> Commit eb70d83a8645 ("RDMA/mana_ib: Adopt robust udata") renamed the
> "flags" field of struct mana_ib_create_cq to "comp_mask", as
> ib_copy_validate_udata_in_cm() only validates a member with that name.
> 
> The layout did not change, but the field has been a part of the UAPI since
> commit 44b607ad4cdf ("RDMA/mana_ib: implement uapi for creation of rnic
> cq"), so the rename breaks userspace referring to it, for example the mana
> provider of rdma-core assigning cmd_drv->flags.
> 
> Convert the field to a union providing both names, so that
> ib_copy_validate_udata_in_cm() still finds "comp_mask" and userspace keeps
> "flags", without having to add a helper for this single case.
> 

Thanks for the patch, but my understanding that it is a common practice to rename the fields,
and kernels headers should not accumulate historical names. 
I also faced a similar problem from renames in other providers, when I needed a new kernel header in rdma-core.
If this breaks your rdma-core in a PR, just remove the field rename in kernel update commit as that header update commit is not getting merged anyway from your PR.
My understanding that maintainers of RDMA-core will merge the kernel header update, and will bring this change from my PR:
https://github.com/linux-rdma/rdma-core/pull/1765/commits/0dcadd9316f1b98e21973e3a6e0f96186d49bd5a

- Konstantin

> Fixes: eb70d83a8645 ("RDMA/mana_ib: Adopt robust udata")
> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
> ---
>  include/uapi/rdma/mana-abi.h | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/include/uapi/rdma/mana-abi.h b/include/uapi/rdma/mana-abi.h
> index 410f0ddc8c89..431c7076f20a 100644
> --- a/include/uapi/rdma/mana-abi.h
> +++ b/include/uapi/rdma/mana-abi.h
> @@ -25,7 +25,10 @@ enum mana_ib_create_cq_flags {
> 
>  struct mana_ib_create_cq {
>  	__aligned_u64 buf_addr;
> -	__u16	comp_mask;
> +	union {
> +		__u16	comp_mask;
> +		__u16	flags; /* the original name of the field */
> +	};
>  	__u16	reserved0;
>  	__u32	reserved1;
>  };
> --
> 2.54.0

Re: [PATCH rdma-next] RDMA/mana_ib: Retain create CQ flags field name

[Jiri Pirko]

Fri, Jul 31, 2026 at 02:54:31PM +0200, kotaranov@microsoft.com wrote:
>> From: Jiri Pirko <jiri@nvidia.com>
>> 
>> Commit eb70d83a8645 ("RDMA/mana_ib: Adopt robust udata") renamed the
>> "flags" field of struct mana_ib_create_cq to "comp_mask", as
>> ib_copy_validate_udata_in_cm() only validates a member with that name.
>> 
>> The layout did not change, but the field has been a part of the UAPI since
>> commit 44b607ad4cdf ("RDMA/mana_ib: implement uapi for creation of rnic
>> cq"), so the rename breaks userspace referring to it, for example the mana
>> provider of rdma-core assigning cmd_drv->flags.
>> 
>> Convert the field to a union providing both names, so that
>> ib_copy_validate_udata_in_cm() still finds "comp_mask" and userspace keeps
>> "flags", without having to add a helper for this single case.
>> 
>
>Thanks for the patch, but my understanding that it is a common practice to rename the fields,
>and kernels headers should not accumulate historical names. 

That is not doable in UAPI. Some userspace app, like rdma-core in
this case, might use it and rename breaks the compilation. Some other
app you don't know about may use it.


>I also faced a similar problem from renames in other providers, when I needed a new kernel header in rdma-core.
>If this breaks your rdma-core in a PR, just remove the field rename in kernel update commit as that header update commit is not getting merged anyway from your PR.
>My understanding that maintainers of RDMA-core will merge the kernel header update, and will bring this change from my PR:
>https://github.com/linux-rdma/rdma-core/pull/1765/commits/0dcadd9316f1b98e21973e3a6e0f96186d49bd5a

this is not how UAPI can be changed :/ It simply can't be changed.


>
>- Konstantin
>
>> Fixes: eb70d83a8645 ("RDMA/mana_ib: Adopt robust udata")
>> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
>> ---
>>  include/uapi/rdma/mana-abi.h | 5 ++++-
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>> 
>> diff --git a/include/uapi/rdma/mana-abi.h b/include/uapi/rdma/mana-abi.h
>> index 410f0ddc8c89..431c7076f20a 100644
>> --- a/include/uapi/rdma/mana-abi.h
>> +++ b/include/uapi/rdma/mana-abi.h
>> @@ -25,7 +25,10 @@ enum mana_ib_create_cq_flags {
>> 
>>  struct mana_ib_create_cq {
>>  	__aligned_u64 buf_addr;
>> -	__u16	comp_mask;
>> +	union {
>> +		__u16	comp_mask;
>> +		__u16	flags; /* the original name of the field */
>> +	};
>>  	__u16	reserved0;
>>  	__u32	reserved1;
>>  };
>> --
>> 2.54.0
>

Re: [PATCH rdma-next] RDMA/mana_ib: Retain create CQ flags field name

[Leon Romanovsky]

On Mon, Aug 03, 2026 at 01:59:07PM +0200, Jiri Pirko wrote:
> Fri, Jul 31, 2026 at 02:54:31PM +0200, kotaranov@microsoft.com wrote:
> >> From: Jiri Pirko <jiri@nvidia.com>
> >> 
> >> Commit eb70d83a8645 ("RDMA/mana_ib: Adopt robust udata") renamed the
> >> "flags" field of struct mana_ib_create_cq to "comp_mask", as
> >> ib_copy_validate_udata_in_cm() only validates a member with that name.
> >> 
> >> The layout did not change, but the field has been a part of the UAPI since
> >> commit 44b607ad4cdf ("RDMA/mana_ib: implement uapi for creation of rnic
> >> cq"), so the rename breaks userspace referring to it, for example the mana
> >> provider of rdma-core assigning cmd_drv->flags.
> >> 
> >> Convert the field to a union providing both names, so that
> >> ib_copy_validate_udata_in_cm() still finds "comp_mask" and userspace keeps
> >> "flags", without having to add a helper for this single case.
> >> 
> >
> >Thanks for the patch, but my understanding that it is a common practice to rename the fields,
> >and kernels headers should not accumulate historical names. 
> 
> That is not doable in UAPI.

There are multiple levels of UAPI contracts. In RDMA, we guarantee
binary compatibility because userspace (rdma-core) is effectively the
second half of the RDMA driver stack. These drivers do not exist
without rdma-core.

As such, this is exactly how the RDMA UAPI is intended to work.


> Some userspace app, like rdma-core in this case, might use it and rename breaks the compilation. Some other
> app you don't know about may use it.

rdma-core does not use these headers directly. Instead, it vendors
them in the kernel-headers directories specifically for this purpose.

> 
> 
> >I also faced a similar problem from renames in other providers, when I needed a new kernel header in rdma-core.
> >If this breaks your rdma-core in a PR, just remove the field rename in kernel update commit as that header update commit is not getting merged anyway from your PR.
> >My understanding that maintainers of RDMA-core will merge the kernel header update, and will bring this change from my PR:
> >https://github.com/linux-rdma/rdma-core/pull/1765/commits/0dcadd9316f1b98e21973e3a6e0f96186d49bd5a
> 
> this is not how UAPI can be changed :/ It simply can't be changed.

It can, at least in RDMA and elsewhere in the kernel, where user
access is provided through properly designed libraries.

Thanks

> 
> 
> >
> >- Konstantin
> >
> >> Fixes: eb70d83a8645 ("RDMA/mana_ib: Adopt robust udata")
> >> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
> >> ---
> >>  include/uapi/rdma/mana-abi.h | 5 ++++-
> >>  1 file changed, 4 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/include/uapi/rdma/mana-abi.h b/include/uapi/rdma/mana-abi.h
> >> index 410f0ddc8c89..431c7076f20a 100644
> >> --- a/include/uapi/rdma/mana-abi.h
> >> +++ b/include/uapi/rdma/mana-abi.h
> >> @@ -25,7 +25,10 @@ enum mana_ib_create_cq_flags {
> >> 
> >>  struct mana_ib_create_cq {
> >>  	__aligned_u64 buf_addr;
> >> -	__u16	comp_mask;
> >> +	union {
> >> +		__u16	comp_mask;
> >> +		__u16	flags; /* the original name of the field */
> >> +	};
> >>  	__u16	reserved0;
> >>  	__u32	reserved1;
> >>  };
> >> --
> >> 2.54.0
> >

Re: [PATCH rdma-next] RDMA/mana_ib: Retain create CQ flags field name

[Jiri Pirko]

Mon, Aug 03, 2026 at 03:28:44PM +0200, leon@kernel.org wrote:
>On Mon, Aug 03, 2026 at 01:59:07PM +0200, Jiri Pirko wrote:
>> Fri, Jul 31, 2026 at 02:54:31PM +0200, kotaranov@microsoft.com wrote:
>> >> From: Jiri Pirko <jiri@nvidia.com>
>> >> 
>> >> Commit eb70d83a8645 ("RDMA/mana_ib: Adopt robust udata") renamed the
>> >> "flags" field of struct mana_ib_create_cq to "comp_mask", as
>> >> ib_copy_validate_udata_in_cm() only validates a member with that name.
>> >> 
>> >> The layout did not change, but the field has been a part of the UAPI since
>> >> commit 44b607ad4cdf ("RDMA/mana_ib: implement uapi for creation of rnic
>> >> cq"), so the rename breaks userspace referring to it, for example the mana
>> >> provider of rdma-core assigning cmd_drv->flags.
>> >> 
>> >> Convert the field to a union providing both names, so that
>> >> ib_copy_validate_udata_in_cm() still finds "comp_mask" and userspace keeps
>> >> "flags", without having to add a helper for this single case.
>> >> 
>> >
>> >Thanks for the patch, but my understanding that it is a common practice to rename the fields,
>> >and kernels headers should not accumulate historical names. 
>> 
>> That is not doable in UAPI.
>
>There are multiple levels of UAPI contracts. In RDMA, we guarantee
>binary compatibility because userspace (rdma-core) is effectively the
>second half of the RDMA driver stack. These drivers do not exist
>without rdma-core.
>
>As such, this is exactly how the RDMA UAPI is intended to work.

That is some odd UAPI...


>
>
>> Some userspace app, like rdma-core in this case, might use it and rename breaks the compilation. Some other
>> app you don't know about may use it.
>
>rdma-core does not use these headers directly. Instead, it vendors
>them in the kernel-headers directories specifically for this purpose.
>
>> 
>> 
>> >I also faced a similar problem from renames in other providers, when I needed a new kernel header in rdma-core.
>> >If this breaks your rdma-core in a PR, just remove the field rename in kernel update commit as that header update commit is not getting merged anyway from your PR.
>> >My understanding that maintainers of RDMA-core will merge the kernel header update, and will bring this change from my PR:
>> >https://github.com/linux-rdma/rdma-core/pull/1765/commits/0dcadd9316f1b98e21973e3a6e0f96186d49bd5a
>> 
>> this is not how UAPI can be changed :/ It simply can't be changed.
>
>It can, at least in RDMA and elsewhere in the kernel, where user
>access is provided through properly designed libraries.

Ehm, up to you. Very loose.


>
>Thanks
>
>> 
>> 
>> >
>> >- Konstantin
>> >
>> >> Fixes: eb70d83a8645 ("RDMA/mana_ib: Adopt robust udata")
>> >> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
>> >> ---
>> >>  include/uapi/rdma/mana-abi.h | 5 ++++-
>> >>  1 file changed, 4 insertions(+), 1 deletion(-)
>> >> 
>> >> diff --git a/include/uapi/rdma/mana-abi.h b/include/uapi/rdma/mana-abi.h
>> >> index 410f0ddc8c89..431c7076f20a 100644
>> >> --- a/include/uapi/rdma/mana-abi.h
>> >> +++ b/include/uapi/rdma/mana-abi.h
>> >> @@ -25,7 +25,10 @@ enum mana_ib_create_cq_flags {
>> >> 
>> >>  struct mana_ib_create_cq {
>> >>  	__aligned_u64 buf_addr;
>> >> -	__u16	comp_mask;
>> >> +	union {
>> >> +		__u16	comp_mask;
>> >> +		__u16	flags; /* the original name of the field */
>> >> +	};
>> >>  	__u16	reserved0;
>> >>  	__u32	reserved1;
>> >>  };
>> >> --
>> >> 2.54.0
>> >

Re: [PATCH rdma-next] RDMA/mana_ib: Retain create CQ flags field name

[Leon Romanovsky]

On Tue, Aug 04, 2026 at 01:08:18PM +0200, Jiri Pirko wrote:
> Mon, Aug 03, 2026 at 03:28:44PM +0200, leon@kernel.org wrote:
> >On Mon, Aug 03, 2026 at 01:59:07PM +0200, Jiri Pirko wrote:
> >> Fri, Jul 31, 2026 at 02:54:31PM +0200, kotaranov@microsoft.com wrote:
> >> >> From: Jiri Pirko <jiri@nvidia.com>
> >> >> 
> >> >> Commit eb70d83a8645 ("RDMA/mana_ib: Adopt robust udata") renamed the
> >> >> "flags" field of struct mana_ib_create_cq to "comp_mask", as
> >> >> ib_copy_validate_udata_in_cm() only validates a member with that name.
> >> >> 
> >> >> The layout did not change, but the field has been a part of the UAPI since
> >> >> commit 44b607ad4cdf ("RDMA/mana_ib: implement uapi for creation of rnic
> >> >> cq"), so the rename breaks userspace referring to it, for example the mana
> >> >> provider of rdma-core assigning cmd_drv->flags.
> >> >> 
> >> >> Convert the field to a union providing both names, so that
> >> >> ib_copy_validate_udata_in_cm() still finds "comp_mask" and userspace keeps
> >> >> "flags", without having to add a helper for this single case.
> >> >> 
> >> >
> >> >Thanks for the patch, but my understanding that it is a common practice to rename the fields,
> >> >and kernels headers should not accumulate historical names. 
> >> 
> >> That is not doable in UAPI.
> >
> >There are multiple levels of UAPI contracts. In RDMA, we guarantee
> >binary compatibility because userspace (rdma-core) is effectively the
> >second half of the RDMA driver stack. These drivers do not exist
> >without rdma-core.
> >
> >As such, this is exactly how the RDMA UAPI is intended to work.
> 
> That is some odd UAPI...

It is not about UAPI itself, but about the rules governing it. The
rule is "don't break userspace"; it does not say "don't break the
build". The latter primarily affects advanced users, who are expected
to be capable of resolving build failures.

Thanks

Re: [PATCH rdma-next] RDMA/mana_ib: Retain create CQ flags field name

[Jason Gunthorpe]

On Mon, Aug 03, 2026 at 01:59:07PM +0200, Jiri Pirko wrote:

> That is not doable in UAPI. Some userspace app, like rdma-core in
> this case, might use it and rename breaks the compilation. Some other
> app you don't know about may use it.

Linus actualy had some comments on this once (which I will never be
able to find I guess), but we broadly follow what he outlined. The
userspace has copies of the kernel headers embedded in it. When the
kernel headers change the user space updates it's copy and fixes any
build breaks.

So long as the build breaks are fixable, and don't change the ABI, it
is fine.

Many parts of the kernel work like this because userspace is not
supposed to directly use the kernel headers themselves, they are
supposed to be sanitized by glibc or some other helper library.

There are a few places that don't work like this of course..

Jason

Re: [PATCH rdma-next] RDMA/mana_ib: Retain create CQ flags field name

[Jiri Pirko]

Sat, Aug 08, 2026 at 01:13:56AM +0200, jgg@ziepe.ca wrote:
>On Mon, Aug 03, 2026 at 01:59:07PM +0200, Jiri Pirko wrote:
>
>> That is not doable in UAPI. Some userspace app, like rdma-core in
>> this case, might use it and rename breaks the compilation. Some other
>> app you don't know about may use it.
>
>Linus actualy had some comments on this once (which I will never be
>able to find I guess), but we broadly follow what he outlined. The
>userspace has copies of the kernel headers embedded in it. When the
>kernel headers change the user space updates it's copy and fixes any
>build breaks.
>
>So long as the build breaks are fixable, and don't change the ABI, it
>is fine.
>
>Many parts of the kernel work like this because userspace is not
>supposed to directly use the kernel headers themselves, they are
>supposed to be sanitized by glibc or some other helper library.
>
>There are a few places that don't work like this of course..

Yeah, me being mainly netdev-guy, that was never allowed there. Not sure
about now. But makes sense. Would be nice to have it explicitly
documented in kernel docs though.

Thanks!