Re: [PATCH rdma-next 1/1] RDMA/mana_ib: Adopt robust udata

[Jason Gunthorpe]

On Fri, Jul 10, 2026 at 08:54:03AM +0000, Konstantin Taranov wrote:
> 
> > On Tue, Jun 23, 2026 at 04:44:43AM -0700, Konstantin Taranov wrote:
> > 
> > > +struct mana_ib_uctx_req {
> > > +	__aligned_u64 client_caps1;
> > > +	__aligned_u64 client_caps2;
> > > +	__aligned_u64 client_caps3;
> > > +	__aligned_u64 client_caps4;
> > > +	__aligned_u64 comp_mask;
> > > +};
> > 
> > I think Jacob has it right, This is looking pretty gross.
> > 
> 
> Jason, I sent a response to Jacob earlier. I am not sure you saw it.
> The problem of enforcing robust udata on alloc user context is that it blocks
> any future additions to the request. Since it is the first IOCTL there is no way
> to negotiate the request format. And that is why I wanted to reserve some fields now.

With the udata system you can't implement a scheme where you send
unknown bits into the kernel and it returns back the ones it
understands. That protocol just isn't supported in the 'zero means
backwards compat' semantic we are using for udata.

So I'd rather not see deviation from that normal protocol (I know a
few other places have but lets not grow)

> > If you want such a complex protocol then use the new ioctl format and
> > declare sensible driver specific attributes. Nobody has converted
> > alloc_ucontext yet, but that is usually not hard to do.
> 
> I have a question. If I add now ib_is_udata_in_empty() to alloc user
> context, would I be able to adopt new ioctl format and extend the
> udata for alloc user context?

Yep, they are orthogonal things. the "udata" is only the legacly uhw
in/out structs. The ioctl mechanism is uattrs based and completely
different.

So you can set an optional client_caps uattr and implement this
protocol there.

Jason