[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