Fixes a bug with user-initiated disconnect that led to failures in deleting the logical unit and target, during concurrent I/O. Typically, the error messages were: > tgtadm: this logical unit is still active > tgtadm: this target is still active (as discussed in the thread "back to forced deletion" starting with http://lists.wpkg.org/pipermail/stgt/2010-September/004095.html) The current tx task (conn->tx_task) was freed using the basic function iscsi_free_task(), while all other pending tx tasks are freed differentially, according to their type. The current tx task also should be freed differentially, or else the task hash table of the nexus remains non-empty and the target is declared active. To achieve this the current tx task is added to the list of pending tx tasks just before their release, so that it is freed according to the same policy. Signed-off-by: Alexander Nezhinsky <alexandern@xxxxxxxxxxxx> --- usr/iscsi/conn.c | 15 ++++++++------- 1 files changed, 8 insertions(+), 7 deletions(-) diff --git a/usr/iscsi/conn.c b/usr/iscsi/conn.c index ba7a58f..b44ca72 100644 --- a/usr/iscsi/conn.c +++ b/usr/iscsi/conn.c @@ -120,6 +120,14 @@ void conn_close(struct iscsi_connection *conn) iscsi_free_task(task); } + if (conn->tx_task) { + dprintf("Add current tx task to the tx list for removal " + "%p %" PRIx64 "\n", + conn->tx_task, conn->tx_task->tag); + list_add(&conn->tx_task->c_list, &conn->tx_clist); + conn->tx_task = NULL; + } + list_for_each_entry_safe(task, tmp, &conn->tx_clist, c_list) { uint8_t op; @@ -158,13 +166,6 @@ void conn_close(struct iscsi_connection *conn) } conn->rx_task = NULL; - if (conn->tx_task) { - eprintf("Forcing release of tx task %p %" PRIx64 "\n", - conn->tx_task, conn->tx_task->tag); - iscsi_free_task(conn->tx_task); - } - conn->tx_task = NULL; - /* cleaning up commands waiting for SCSI_DATA_OUT */ list_for_each_entry_safe(task, tmp, &conn->task_list, c_siblings) { /* -- 1.6.5 -- 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