Re: Possible Bug? LIO does not support SCSI commands with Immediate Bit Set?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 2023-11-26 at 18:39 -0600, Mike Christie wrote:
> On 11/26/23 6:01 AM, Hannes Reinecke wrote:
> > On 11/25/23 19:28, Lee Duncan wrote:
> > > 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.
> > 
> > Sounds like a bug.
> > Can you check if this helps?
> > 
> > diff --git a/drivers/target/iscsi/iscsi_target.c
> > b/drivers/target/iscsi/iscsi_target.c
> > index b516c2893420..ad68706ad9f7 100644
> > --- a/drivers/target/iscsi/iscsi_target.c
> > +++ b/drivers/target/iscsi/iscsi_target.c
> > @@ -1060,7 +1060,8 @@ int iscsit_setup_scsi_cmd(struct iscsit_conn
> > *conn, struct iscsit_cmd *cmd,
> > 
> > ISCSI_REASON_BOOKMARK_INVALID, buf);
> >         }
> > 
> > -       if (hdr->opcode & ISCSI_OP_IMMEDIATE) {
> > +       if ((hdr->opcode & ISCSI_OP_IMMEDIATE) &&
> > +           !conn->sess->sess_ops->ImmediateData) {
> >                 pr_err("Illegally set Immediate Bit in iSCSI
> > Initiator"
> >                                 " Scsi Command PDU.\n");
> >                 return iscsit_add_reject_cmd(cmd,
> > 
> 
> 
> These are different things.
> 
> Immediate data means you can have data after the header in the PDU.
> 
> The immediate bit on the header has CmdSN rules which allows you to
> send commands without having to increment the CmdSN. It's used for
> things like TMFs because at that time, the window might be closed due
> to SCSI commands having filled it.
> 
> 

I have iscsi booted for years with LIO as the target but never with
qedi as the base ISCSI driver. I will see if I see the same behavior as
Lee with the qedi involved.







[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux