On Tue, Aug 19, 2014 at 1:28 PM, Doug Ledford <[email protected]> wrote:
> So that's why in this patch we > > 1) take a mutex to force ib_sa_join_multicast to return and us to set > mcast->mc to the proper return value before we process the join completion > callback > 2) always clear mcast->mc if there is any error since we can't call > ib_sa_multicast_leave > 3) always complete the mcast in case we are waiting on it > 4) only if our status is ENETRESET set our return to 0 so the ib core code > knows we acknowledged the event > We don't have IPOIB_MCAST_JOIN_STARTED (and the "done" completion struct) in our code base (MPSS) yet ...I'm *not* n-acking this patch but I find it hard to understand the ramifications. It has nothing to do with this patch - actually the patch itself looks pretty ok (by eyes). The original IPOIB mcast flow, particularly its abnormal error path, confuses me. Is it really possible for ib_sa_join_multicast() to return *after* its callback (ipoib_mcast_sendonly_join_complete and ipoib_mcast_join_complete) ? The mcast->done completion struct looks dangerous as well. I'll let other capable people to do the final call(s). -- Wendy -- 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
