On Mon, Apr 20, 2015 at 7:41 PM, Jason Gunthorpe <jgunthorpe@xxxxxxxxxxxxxxxxxxxx> wrote: > On Mon, Apr 20, 2015 at 12:03:32PM +0300, Haggai Eran wrote: >> From: Yotam Kenneth <yotamke@xxxxxxxxxxxx> >> >> When accepting a new connection with the listener being IPv6, the >> family of the new connection is set as IPv6. This causes cma_zero_addr >> function to return true on an non-zero address. As a result, the wrong >> code path is taken. This causes the connection request to be rejected, >> as the RDMA-CM code looks for the wrong type of device. > > This description doesn't really make sense as to what the problem is. > >> @@ -866,12 +866,12 @@ static void cma_save_ip4_info(struct rdma_cm_id *id, struct rdma_cm_id *listen_i >> >> listen4 = (struct sockaddr_in *) &listen_id->route.addr.src_addr; >> ip4 = (struct sockaddr_in *) &id->route.addr.src_addr; >> - ip4->sin_family = listen4->sin_family; >> + ip4->sin_family = AF_INET; > > If listen_id->route.addr.src_addr.ss_family != AF_INET then it is > invalid to cast to sockaddr_in. > > So listen4->sin_family MUST be AF_INET or this function MUST NOT be > called. > > Forcing to AF_INET cannot be correct here. Jason, could you take a look @ this thread http://marc.info/?t=141589395000004&r=1&w=2 where the authors addressed some comments from Sean and he eventually Acked the patch? > What does this patch have to do with this series? I believe it's either a pre-patch to address some assumption or something they stepped on while testing Or. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
