On 07/31/2009 09:53 AM, Hannes Reinecke wrote:
> Hmm. I must admit I'm slightly at a loss here.
> I do have this function:

Did you try my second patch queue-some-io-during-tmfs2.patch

or read the mail about why I sent a second version? I was accessing 
hdr/task values that were not set yet like you have below, so the checks 
are failing/succeeding when you do not  want them do and letting IO in.

Or did you try the simple patch? Here is a different one. Please just 
try the attached patch. It fixes the problem for scsi cmd pdus at least. 
We are checking for just if the tmf was queued for new commands, which 
is wrong, because when it transitions we allow new commands, and then 
clean them by accident when they are valid running tasks because they 
were not affected by the lu reset.

> static int iscsi_check_tmf_restrictions(struct iscsi_task *task, int opcode)
> {
>       struct iscsi_conn *conn = task->conn;
>       struct iscsi_tm *tmf =&conn->tmhdr;
>       unsigned int hdr_lun, task_lun;
>       if (iscsi_conn_tmf_state(conn) == TMF_INITIAL)
>               return 0;
>       if ((tmf->opcode&  ISCSI_OPCODE_MASK) != ISCSI_OP_SCSI_TMFUNC) {
>               iscsi_conn_printk(KERN_INFO, conn,
>                                 "ignore tmf op %x\n", tmf->opcode);
>               return 0;
>       }
>       hdr_lun = scsilun_to_int((struct scsi_lun *)tmf->lun);
>       task_lun = scsilun_to_int((struct scsi_lun *)task->lun);

This is not set yet for scsi cmd pdus.

>       switch (ISCSI_TM_FUNC_VALUE(tmf)) {
>               /* Skip unaffected LUNs */
>               if (hdr_lun != task_lun)
>                       return 0;
>               /*
>                * all scsi cmd pdus and, if fast_abort is set, data-outs
>                * in response to a r2t will fail to be sent here
>                *
>                * If we are sending a initial r2t with a scsi cmd pdu
>                * we do not hit this test, but the tmf will be sent
>                * after the scsi cmd pdu and data-out for the initial r2t.
>                */
>               if (conn->session->fast_abort) {
>                       iscsi_conn_printk(KERN_INFO, conn,
>                                         "task [op %x itt 0x%x lun %u] "
>                                         "fast abort.\n",
>                                         task->hdr->opcode, task->hdr->itt,

For scsi cmd pdus, we have not prepd the header so opcode is not set here.

>                                         hdr_lun);
>                       return -EACCES;
>               }
>               /* Continue with R2T response */
>               if ((task->hdr->opcode&  ISCSI_OPCODE_MASK) !=
>                   ISCSI_OP_SCSI_DATA_OUT) {

opcode not set for scsi cmd pdus, so you are going to allow the cmd to 
be sent.

What was wrong with my second patch queue-some-io-during-tmfs2.patch? 
The second patch should have fixed this.

Just try the attached simple one to fix the scsi cmd pdu being sent 
problem. It was just a bad state check. These other complex patches are 
not going to buy us anything unless we add more complicated queueing code.

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at http://groups.google.com/group/open-iscsi

diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index a751f62..bcdc72e 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -1295,7 +1295,7 @@ check_mgmt:
        /* process pending command queue */
        while (!list_empty(&conn->cmdqueue)) {
-               if (conn->tmf_state == TMF_QUEUED)
+               if (conn->tmf_state != TMF_INITIAL)
                conn->task = list_entry(conn->cmdqueue.next,

Reply via email to