[stgt] [PATCH 2/2] iscsi user-initiated disconnect fix: scheduling mtask processing

Alexander Nezhinsky alexandern at Voltaire.COM
Thu Nov 11 16:37:56 CET 2010


On 11/09/2010 03:49 AM, FUJITA Tomonori wrote:

>> The solution implemented here is to schedule an event that calls the original
>> mtask-processing code instead of processing it on the spot.
>> Because the scheduled events are serviced after all epoll_wait() events are handled,
>> this guarantees that the connection is destroyed when no epoll_wait-detected fds 
>> are waiting. After that epoll_wait() won't detect anything related to the connection,
>> as its fd is already removed from epoll records.

> We can avoid this bug with the following patch?
> 
> I think that we can't call conn_close in conn_close_force.
> 
> http://lists.wpkg.org/pipermail/stgt/2010-September/004148.html

In this specific case the above patch indeed solves the problem.
But i think we may need to have both patches in place.

The patch that you mentioned implements connection closing right,
i guess it is ok anyway.

The patch i've sent solves a general problem. In iser this kind of
scenario may also happen, although with very low probability.
There is no event_modify function in the new implementation, so
the other patch does not apply directly, and all depends on the 
implementation. In iser the connection close function only invokes 
RDMA disconnect primitive, but the RDMA event for the actual disconnection 
may arrive theoretically before we return to the event loop 
(if it is retrieved by polling the CQ within the same event handler), 
so we may end up destroying the CQ's fd before we return.

This scenario may be circumvented by scheduling connection close
(actually iser uses scheduled events in all those places event_modify
used to be), but the general solution solves all such cases.

So what about having both patches, each one in its own right?
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



More information about the stgt mailing list