Oh...please, commit ! But in the future, when CM mode will be released, the code should be like: ipoib_addr_set_flags( &p_ib_arp->src_hw, p_port->p_adapter->params.cm_enabled ? IPOIB_CM_FLAG_RC : 0 );
-----Original Message----- From: Smith, Stan [mailto:[email protected]] Sent: Monday, September 13, 2010 10:47 PM To: Alex Naslednikov Cc: [email protected] Subject: [PATCH] ipoib_ndis6_cm - prevent UD IPoIB from falsely advertizing a Connect Mode capability. Hello, Here is a curious bug for your inspection. In the case where a UD [non-CM (Connected Mode)] IPoIB receives an ARP Request from a CM enabled IPoIB, the UD IPoIB can falsely advertise a CM (Connect Mode) capability in the ARP Reply src hardware address due to an uninitialized CM flags field. The ARP reply packet is constructed from a send_buf_list allocated buffer. The cm field byte of the src hardware address in the ARP Request never gets initialized, hence the IPoIB UD ARP reply can falsely advertise a CM capability depending on the value of the CM capability byte; turns out 1 is a somewhat common memory value. :-) It's not a problem for UD IPoIB talking to another UD IPoIB; CM flags are ignored. OFED/Linux CM IPoIB would attempt to RC connect which would fail. The fix is to always set the CM capabilities byte of the ARP Reply src hardware address.flags_qpn field with the current IPoIB CM capability byte. signed-off-by: stan smith <[email protected]> --- a/ulp/ipoib_NDIS6_CM/kernel/ipoib_port.cpp Mon Sep 13 13:08:48 2010 +++ b/ulp/ipoib_NDIS6_CM/kernel/ipoib_port.cpp Mon Sep 13 11:18:39 2010 @@ -4891,6 +4891,7 @@ p_ib_arp->op = p_arp->op; ipoib_addr_set_qpn( &p_ib_arp->src_hw, s_buf->p_port->ib_mgr.qpn ); + ipoib_addr_set_flags( &p_ib_arp->src_hw, 0 ); #if 0 if( p_port->p_adapter->params.cm_enabled ) _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
