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

[FUJITA Tomonori]

On Thu, 11 Nov 2010 17:37:56 +0200
Alexander Nezhinsky <alexandern at Voltaire.COM> wrote:

> 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?

But that patch only guarantees that mtaks is executed after all epoll
events? We must still obey the rule that each epoll event must be
independent? As long as we obey the rule, we are fine without that
patch, I think.
--
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