[openib-general] [PATCH 4/7] IB/ipath - performance improvements via mmap of queues

[ralphc at pathscale.com]

>  >  struct ib_uverbs_resize_cq_resp {
>  >  	__u32 cqe;
>  > +	__u32 reserved;
>  > +	__u64 driver_data[0];
>  >  };
>
> I don't see any changes related to this in uverbs_cmd.c, and you don't
> bump the ABI version.  So as far as I can tell, ib_uverbs_resize_cq()
> will silently corrupt the stack on an old libibverbs that passes in a
> pointer to a 4-byte response structure.
>
> In general I've resisted putting backwards compatibility stuff into
> the kernel side of uverbs, so maybe an ABI bump is the answer in this
> case too.
>
> But then I have to do another libibverbs 1.0 release etc., which is
> kind of a pain.  So in this case it's probably OK to add a check in
> ib_uverbs_resize_cq() for when out_len == 4, and not overflow the
> response buffer in that case.
>
>  - R.

This doesn't break compatibility.  uverbs_cmd.c ib_uverbs_resize_cq()
allocates a struct ib_uverbs_resize_cq_resp on the stack but
only reads the first element in.
The structure change isn't really needed at all since the INIT_UDATA()
macro gets the start of driver_data from the struct ib_uverbs_resize_cq.
The change to ib_uverbs_resize_cq_resp just matches the structure
change used by libipathverbs to initialize ib_uverbs_resize_cq.response.

If you want, I can remove this from the patch.