On Sun, 07 Nov 2010 19:00:22 +0200 Alexander Nezhinsky <alexandern@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
