1. 02 May, 2017 17 commits
  2. 02 Apr, 2017 2 commits
    • Xiubo Li's avatar
      tcmu: Skip Data-Out blocks before gathering Data-In buffer for BIDI case · a5d68ba8
      Xiubo Li authored
      For the bidirectional case, the Data-Out buffer blocks will always at
      the head of the tcmu_cmd's bitmap, and before gathering the Data-In
      buffer, first of all it should skip the Data-Out ones, or the device
      supporting BIDI commands won't work.
      
      Fixed: 26418649 ("target/user: Introduce data_bitmap, replace
      		data_length/data_head/data_tail")
      Reported-by: default avatarIlias Tsitsimpis <iliastsi@arrikto.com>
      Tested-by: default avatarIlias Tsitsimpis <iliastsi@arrikto.com>
      Signed-off-by: default avatarXiubo Li <lixiubo@cmss.chinamobile.com>
      Cc: stable@vger.kernel.org # 4.6+
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      a5d68ba8
    • Nicholas Bellinger's avatar
      iscsi-target: Drop work-around for legacy GlobalSAN initiator · 1c99de98
      Nicholas Bellinger authored
      Once upon a time back in 2009, a work-around was added to support
      the GlobalSAN iSCSI initiator v3.3 for MacOSX, which during login
      did not propose nor respond to MaxBurstLength, FirstBurstLength,
      DefaultTime2Wait and DefaultTime2Retain keys.
      
      The work-around in iscsi_check_proposer_for_optional_reply()
      allowed the missing keys to be proposed, but did not require
      waiting for a response before moving to full feature phase
      operation.  This allowed GlobalSAN v3.3 to work out-of-the
      box, and for many years we didn't run into login interopt
      issues with any other initiators..
      
      Until recently, when Martin tried a QLogic 57840S iSCSI Offload
      HBA on Windows 2016 which completed login, but subsequently
      failed with:
      
          Got unknown iSCSI OpCode: 0x43
      
      The issue was QLogic MSFT side did not propose DefaultTime2Wait +
      DefaultTime2Retain, so LIO proposes them itself, and immediately
      transitions to full feature phase because of the GlobalSAN hack.
      However, the QLogic MSFT side still attempts to respond to
      DefaultTime2Retain + DefaultTime2Wait, even though LIO has set
      ISCSI_FLAG_LOGIN_NEXT_STAGE3 + ISCSI_FLAG_LOGIN_TRANSIT
      in last login response.
      
      So while the QLogic MSFT side should have been proposing these
      two keys to start, it was doing the correct thing per RFC-3720
      attempting to respond to proposed keys before transitioning to
      full feature phase.
      
      All that said, recent versions of GlobalSAN iSCSI (v5.3.0.541)
      does correctly propose the four keys during login, making the
      original work-around moot.
      
      So in order to allow QLogic MSFT to run unmodified as-is, go
      ahead and drop this long standing work-around.
      Reported-by: default avatarMartin Svec <martin.svec@zoner.cz>
      Cc: Martin Svec <martin.svec@zoner.cz>
      Cc: Himanshu Madhani <Himanshu.Madhani@cavium.com>
      Cc: Arun Easi <arun.easi@cavium.com>
      Cc: stable@vger.kernel.org # 3.1+
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      1c99de98
  3. 31 Mar, 2017 5 commits
  4. 30 Mar, 2017 6 commits
  5. 19 Mar, 2017 10 commits