opensm/osm_torus.c: avoid the possibility of following stale ->priv pointers
PATCH 1/2 opensm/osm_torus.c: avoid the possibility of following stale ->priv pointers
Quoted 1 line
From
557b01eb8857a197a973af76d1322f76d25495edMon Sep 17 00:00:00 2001
From: Jim Schutt <[email protected]>
Date: Fri, 8 Mar 2013 08:59:01 -0700
Subject: [PATCH 1/2] opensm/osm_torus.c: avoid the possibility of following stale ->priv pointers
Torus-2QoS makes persistent use of osm_switch_t:priv and osm_port_t:priv to speed its routing calculations.
In some situations t2q is unable to determine the location in the torus topology of a discovered switch. An example of this occurs when all the inter-switch links but one connected to a switch have failed.
When this happens, at the end of a full sweep opensm will attempt to program the VLArb tables for that switch. Torus_update_osm_vlarb() will follow a stale osm_switch_t:priv pointer, left over from the previous routing cycle when switch was discovered in the torus, ultimately resulting in a segmentation fault.
Prevent this by clearing stale values of osm_switch_t:priv as part of the first step in torus topology discovery. Do the same thing for osm_port_t:priv, even though it has not yet been implicated in this sort of issue yet.
--- opensm/osm_torus.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
opensm/osm_torus.c +2 -0
@@ -1173,6 +1173,7 @@ bool capture_fabric(struct fabric *fabric) osm_sw = (osm_switch_t *)item; item =cl_qmap_next (item); + osm_sw->priv =NULL ;/* avoid stale pointer dereferencing */ osm_node = osm_sw->p_node;if (osm_node_get_type (osm_node) !=IB_NODE_TYPE_SWITCH )
@@ -1193,6 +1194,7 @@ bool capture_fabric(struct fabric *fabric) lport = (osm_port_t *)item; item =cl_qmap_next (item); + lport->priv =NULL ;/* avoid stale pointer dereferencing */ lphysp = lport->p_physp;if (!(lphysp &&osm_physp_is_valid (lphysp)))
Signature · 6 lines
1.7.1 -- 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