> > Set max_inline_data to zero during RC QP creation.
> >
> > Fixes: fdefb9184962 ("RDMA/mana_ib: Implement uapi to create and
> > destroy RC QP")
> > Signed-off-by: Konstantin Taranov <kotaranov@xxxxxxxxxxxxx>
> > ---
> > drivers/infiniband/hw/mana/qp.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/infiniband/hw/mana/qp.c
> > b/drivers/infiniband/hw/mana/qp.c index 73d67c853b6f..d9f24a763e72
> > 100644
> > --- a/drivers/infiniband/hw/mana/qp.c
> > +++ b/drivers/infiniband/hw/mana/qp.c
> > @@ -426,6 +426,8 @@ static int mana_ib_create_rc_qp(struct ib_qp *ibqp,
> struct ib_pd *ibpd,
> > u64 flags = 0;
> > u32 doorbell;
> >
> > + /* inline data is not supported */
> > + attr->cap.max_inline_data = 0;
>
> Can you please point to me to the flow where attr is not zeroed before?
>
Sorry, I do not understand the question. I cannot point to something that is not in the code.
It is to support the case when user asks for x bytes inlined
when it creates a QP, and we respond with actual allowed inline
data for the created QP. (as defined in: "The function ibv_create_qp()
will update the qp_init_attr->cap struct with the actual QP values of
the QP that was created;")
The kernel logic is inside "static int create_qp(struct uverbs_attr_bundle *attrs, struct ib_uverbs_ex_create_qp *cmd)"
where we do the following:
attr.cap.max_inline_data = cmd->max_inline_data;
qp = ib_create_qp_user(..,&attr,..);
resp.base.max_inline_data = attr.cap.max_inline_data;
So, my change makes sure that the response will have 0 and not the value the user asked,
as we do not support inlining. So without the fix, the user who was asking for inlining was falsely
seeing that we support it (example of such an application is rdma_server from librdmacm).
Thanks
> Thanks
>
> > if (!udata || udata->inlen < sizeof(ucmd))
> > return -EINVAL;
> >
> > --
> > 2.43.0
> >
