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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
