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

[FUJITA Tomonori]

On Sun, 07 Nov 2010 19:00:22 +0200
Alexander Nezhinsky <alexandern at Voltaire.COM> wrote:

> Fixes another bug with user-initiated disconnect. It led to segfaults
> when deleting an iscsi connection during concurrent I/O.
> 
> Processing of managements tasks (mtasks) has been performed in the main event loop.
> When epoll_wait() returns, it saves all signaled file descriptors in an array, 
> and those are processed one by one. There is a tacit assumption that every event 
> is processed separately and independently of other events. Still, in case of mtasks
> there may be a dependency between handling an mtask and the remaining events.
> When a management request asking for connection removal arrives during a heavy
> traffic, there is a high probability that the tcp socket of the iscsi connection
> is also signaled. If the management fd is processed first (which is guaranteed,
> as it is created and added to epoll first), then the connection and all its 
> associated data incl. the tcp-related event itself are destroyed.
> When the turn of this deleted tcp-related event in the epoll_wait-filled array
> comes, we end up referencing garbage.
> 
> 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
--
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