On Tue, Jul 19, 2011 at 09:20:25PM +0000, Hefty, Sean wrote: > > More clearly: what initializes the memory you've redefined to be > > link_layer in libibverbs 1.1.5 ? I see nothing. > > Why does the value in an older library cause an issue?
ABI compatability means if dynamic linking succeeds then the result works, so the behavior of a new app, using new functionality when it links to the old library must work. The commit comment states the goal is to have new apps see IBV_LINK_LAYER_UNSPECIFIED for all possible combinations of old stuff underneath. > Or, how will this library version interact with an older kernel? The kernel interaction is not what I'm talking about - AFAIK, the kernel interaction is OK. Old kernels zero the entire ib_port_attr structure before copy_to_user so the reserved bytes are guaranteed to be 0. The problem is with the userspace ABI out of libibverbs. Current libibverbs does not zero its ib_port_attr structure before returning. Build this with Or's patch applied, then run it against libibverbs 1.1.5 struct ibv_port_attr attr; attr.link_layer = 100; ibv_query_port(..,&attr); assert(attr.link_layer == IBV_LINK_LAYER_UNSPECIFIED); // Fails! That is an ABI breaking issue that is not dealt with by Or's patch. Couple choices: 1) Require and document callers using ibv_query_port to zero attr before hand when using link_layer 2) Crank the symbol version on ibv_query_port so dynamic linking fails 3) Inline the memset in ibverbs.h: static inline int fixed_ibv_query_port(...) { attr->link_layer = 0; return ibv_query_port(...); } #define ibv_query_port(...) fixed_ibv_query_port(...) #2 might be the best? Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html