RE: [openib-general] Re: [PATCH 1/2] iWARP Connection Manager.

quoted

There's a difference between trying to handle the user calling
disconnect/destroy at the same time a call to accept/connect is
active, versus the user calling disconnect/destroy after
accept/connect have returned.  In the latter case, I think you're
fine.  In the first case, this is allowing a user to call

destroy at the same time that they're calling accept/connect.

quoted

Additionally, there's no guarantee that the F_CONNECT_WAIT flag has
been set by accept/connect by the time disconnect/destroy tests it.

The problem is that we can't synchronously cancel an
outstanding connect request. Once we've asked the adapter to
connect, we can't tell him to stop, we have to wait for it to
fail. During the time period between when we ask to connect
and the adapter says yeah-or-nay, the user hits ctrl-C. This
is the case where disconnect and/or destroy gets called and
we have to block it waiting for the outstanding connect
request to complete.

One alternative to this approach is to do the kfree of the
cm_id in the deref logic. This was the original design and
leaves the object around to handle the completion of the
connect and still allows the app to clean up and go away
without all this waitin' around. When the adapter finally
finishes and releases it's reference, the object is kfree'd.

Hope this helps.

Why couldn't you synchronously put the cm_id in a state of
"pending delete" and do the actual delete when the RNIC
provides a response to the request? There could even be
an optional method to see if the device is capable of
cancelling the request. I know it can't yank a SYN back
from the wire, but it could refrain from retransmitting.

quoted

The problem is that we can't synchronously cancel an
outstanding connect request. Once we've asked the adapter to
connect, we can't tell him to stop, we have to wait for it to
fail. During the time period between when we ask to connect
and the adapter says yeah-or-nay, the user hits ctrl-C. This
is the case where disconnect and/or destroy gets called and
we have to block it waiting for the outstanding connect
request to complete.

One alternative to this approach is to do the kfree of the
cm_id in the deref logic. This was the original design and
leaves the object around to handle the completion of the
connect and still allows the app to clean up and go away
without all this waitin' around. When the adapter finally
finishes and releases it's reference, the object is kfree'd.

Hope this helps.

Why couldn't you synchronously put the cm_id in a state of
"pending delete" and do the actual delete when the RNIC
provides a response to the request? 

This is Tom's "alternative" mentioned above.  The provider already keeps
an explicit reference on the cm_id while it might possibly deliver an
event on that cm_id.  So if you change deref to kfree the cm_id on its
last deref (when the refcnt reaches 0), then you can avoid blocking
during destroy...  

There could even be
an optional method to see if the device is capable of
cancelling the request. I know it can't yank a SYN back
from the wire, but it could refrain from retransmitting.

I would suggest we don't add this optional method until we see an RNIC
that supports canceling a connect request or accept synchronously...

Steve.