On 5/13/08, <b class="gmail_sendername">Roland Dreier</b> <<a href="mailto:rdreier@cisco.com">rdreier@cisco.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
 > Use netevent notification for sensing that a change has happened in the IP stack,<br>  > then scan the rdma-cm IDs list to see if there is an ID that is "misaligned"<br>  > in that respect with the IP stack, and disconnect it, in case this is what the<br>
  > user asked to when setting an ha mode for the ID.<br> <br>this seems like a strange "HA" feature -- to disconnect connections that<br> otherwise would continue operating.  What is the use case/use scenario?</blockquote>
<div><br>
OK, I might went too fast here. The idea is to align the RDMA traffic
with the links used by the IP stack. In the case where the app takes
advantage of bonding ipoib devices to achieve HA AND it want this
alignment, when bonding does fail-over from --any-- reason (eg the
problem is fixed and the primary option is used) a "fail-back" of the
connection is needed.<br>
<br>
(*) HW error --> RC connection break && bonding failover
(change of active slave device, send gratuitous ARP), then this app
reconnects and its back in the business.<br>
<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">  > +    list_for_each_entry(cma_dev, &dev_list, list)<br>  >
+            list_for_each_entry(id_priv,
&cma_dev->id_list, list) {<br>  >
+                    dev_addr
= &id_priv->id.route.addr.dev_addr;<br>  >
+                    if
(!memcmp(dev_addr->src_netdev_name, ndev->name, IFNAMSIZ) &&<br>  >
+                            memcmp(dev_addr->src_dev_addr,
ndev->dev_addr, ndev->addr_len))<br>  >
+                                    if
(id_priv->ha_mode == RDMA_ALIGN_WITH_NETDEVICE)<br>  >
+                                            schedule_work(&id_priv->ha_work);<br>  > +            }<br> <br> <br>This looks horribly racy/incorrect against RDMA device removal, CMA ID<br> destruction and netdev renaming.</blockquote>
<div><br>
mmm, bad. I see your point re the first two, that is some locking is
needed to protect against device removal, the ID should be referenced,
etc. As for the netdev renaming, I don't see how making a decsion based
on memcmp(dev_addr->src_dev_name, ndev->name, IFNAMSIZ) is racy?!
even for the crazy case the ndev->name gets changed in the middle of
this memcmp, the only issue would be some confusion made by the code,
no damage.<br>
 </div>Or.<br></div>