Target-devel archive mirror
 help / color / mirror / Atom feed
From: Lee Duncan <lduncan@suse.com>
To: target-devel <target-devel@vger.kernel.org>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	Chris Leech <cleech@redhat.com>,
	Mike Christie <michael.christie@oracle.com>
Subject: Possible Bug? LIO does not support SCSI commands with Immediate Bit Set?
Date: Sat, 25 Nov 2023 10:28:51 -0800	[thread overview]
Message-ID: <31851279-0884-48ba-8c4b-7d6147e59508@suse.com> (raw)

Hi Martin/list:

I am trying to track down an issue I am seeing when trying to boot using 
iSCSI root using the fastlinq qedi converged network adapter initiator 
and an LIO target.

In this configuration, but using a non-LIO (hardware) iSCSI target, 
everything "just works". But when I switch to using an LIO software 
target, I get this error when booting:

> 2023-09-20T14:10:32.835358-0500 worker5 kernel: Illegally set Immediate Bit in iSCSI Initiator Scsi Command PDU.
> ... > 2023-09-20T14:10:32.835422-0500 worker5 kernel: Got unknown iSCSI 
OpCode: 0x52

It looks like the fastlinq adapter is sending a SCSI write (0x12) with 
the Immediate bit set (0x40).

The code in iscsi_target.c:iscsit_setup_scsi_cmd(): looks like this:

> 	if (hdr->opcode & ISCSI_OP_IMMEDIATE) {
> 		pr_err("Illegally set Immediate Bit in iSCSI Initiator"
> 				" Scsi Command PDU.\n");
> 		return iscsit_add_reject_cmd(cmd,
> 					     ISCSI_REASON_BOOKMARK_INVALID, buf);
> 	}
> 

But I looked at rfc3720, and it looks like SCSI PDUs can have the 
Immediate Bit set:

> 10.3.  SCSI Command
>     
>    The format of the SCSI Command PDU is:
>             
>    Byte/     0       |       1       |       2       |       3       |
>       /              |               |               |               |
>      |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
>      +---------------+---------------+---------------+---------------+
>     0|.|I| 0x01      |F|R|W|. .|ATTR | Reserved                      |
>      +---------------+---------------+---------------+---------------+
>     4|TotalAHSLength | DataSegmentLength                             |
>      +---------------+---------------+---------------+---------------+
>     8| Logical Unit Number (LUN)                                     |
>      +                                                               +
>    12|                                                               |
>      +---------------+---------------+---------------+---------------+
> ...

Where "I" is the immediate bit.

Frankly, I'm never sure I read the SPEC correctly, so I'm not sure if 
I'm mistaken here, but it looks like LIO does not allow the Immediate 
bit (and hence Immediate data), even though the SPEC does allow it. But 
it also looks like, during negotiation phase, LIO negotiates 
ImmediateData like any other parameter, allowing "YES".

In our testing, if we set ImmediateData=No in the target, then our 
problem goes away, i.e. we can now boot from an LIO target. This is 
because Immediate Data is negotiated off, of course.

Is this a bug, or is this adapter doing something wrong? I would 
appreciate other viewpoints.

Thank you.
-- 
Lee Duncan

             reply	other threads:[~2023-11-25 18:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-25 18:28 Lee Duncan [this message]
2023-11-26 12:01 ` Possible Bug? LIO does not support SCSI commands with Immediate Bit Set? Hannes Reinecke
2023-11-27  0:39   ` Mike Christie
2023-11-27 19:01     ` Laurence Oberman
2023-11-27 20:23     ` Lee Duncan
2023-11-27 20:44       ` Mike Christie
2023-11-27 22:08         ` Lee Duncan
2023-12-06 22:50 ` Lee Duncan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=31851279-0884-48ba-8c4b-7d6147e59508@suse.com \
    --to=lduncan@suse.com \
    --cc=cleech@redhat.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=michael.christie@oracle.com \
    --cc=target-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).