Re: remaining flexible-array conversions
On Thu, Oct 08, 2020 at 05:24:03PM +0200, Jan Engelhardt wrote: > In the case of the RDMA headers, even if we assume best conditions -- > a block of malloc(sizeof(struct ib_uverbs_create_cq_resp) + > sizeof(u64)*N) and not some struct -- it smells a lot like undefined > behavior, because ib_uverbs_create_cq_resp::driver_data accesses data > as u64 driver_data[] is never accessed, it is only used as a pointer. Aliasing should be OK because all accesses to those bytes consistently use u32. Fixing the compiler warning requires significant edits of kernel and user code, not entirely sure it is worthwhile. If someone wants to do it let me know and I'll give some guidance. Jason
Re: remaining flexible-array conversions
On Friday 2020-04-24 14:15, Jason Gunthorpe wrote: >> ./usr/include/rdma/ib_user_verbs.h:436:34: warning: field 'base' with >> variable sized type 'struct ib_uverbs_create_cq_resp' not at the end of >> a struct or class is a GNU extension >> [-Wgnu-variable-sized-type-not-at-end] >> struct ib_uverbs_create_cq_resp base; >> ^ >> I presume this is part of the point of the conversion since you mention >> a compiler warning when the flexible member is not at the end of a >> struct. How should they be fixed? That should probably happen before the >> patch gets merged. > >The flexible member IS at the end of the struct and is often intended >to cover the memory in the enclosing struct. There is no guarantee for the presence of such a struct. In the case of the RDMA headers, even if we assume best conditions -- a block of malloc(sizeof(struct ib_uverbs_create_cq_resp) + sizeof(u64)*N) and not some struct -- it smells a lot like undefined behavior, because ib_uverbs_create_cq_resp::driver_data accesses data as u64 while ib_uverbs_ex_create_cq_resp::comp_mask and friends are u32. There has got to be some aliasing rule in C that causes RDMA's purported use-case to be UB.
