[ofw] [PATCH] checked ipoib_ndis6_cm shutdown race

[Smith, Stan]

Hefty, Sean wrote:
>> The fix is to recognize the port is not in the IB_QPS_RTS state, do
>> not schedule an IO work thread request and continue to pull recv
>> work requests from the CQ until empty.
>
> What prevents the port->state from changing immediately after the
> work thread is queued and ending up in the same situation?

When the Work thread runs, the mods to __recv_cb_internal() will return 'More work to do' for the case of !IB_QPS_RTS, the IO work thread will continue to reap WorkRequests until a max of 512 has been reached.
More likely is the case of the dispatch-level CQ callback routine will empty the CQ of WorkRequests and the IO thread will find nothing to do.
An interesting case is if the IO thread is running and the dispatch-level CQ callback occurs.
Perhaps the CQ callback for the case of !IB_QPS_RTS should cancel/notify in-flight/in-progress work-thread?

>
> If holding a reference on the port doesn't work, then it sounds like
> the use of a worker thread is inherently racy and not usable.