1. 03 10月, 2012 14 次提交
  2. 23 9月, 2012 2 次提交
  3. 18 9月, 2012 21 次提交
  4. 08 9月, 2012 3 次提交
    • P
      target: go through normal processing for zero-length REQUEST_SENSE · 6abbdf38
      Paolo Bonzini 提交于
      Now that spc_emulate_request_sense has been taught to process zero-length
      REQUEST SENSE correctly, drop the special handling of unit attention
      conditions from transport_generic_new_cmd.  However, for now REQUEST SENSE
      will be the only command that goes through emulation for zero lengths.
      
      (nab: Fix up zero-length check in transport_generic_new_cmd)
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      6abbdf38
    • P
      target: support zero allocation length in REQUEST SENSE · 32a8811f
      Paolo Bonzini 提交于
      Similar to INQUIRY and MODE SENSE, construct the sense data in a
      buffer and later copy it to the scatterlist.  Do not do anything,
      but still clear a pending unit attention condition, if the allocation
      length is zero.
      
      However, SPC tells us that "If a REQUEST SENSE command is terminated with
      CHECK CONDITION status [and] the REQUEST SENSE command was received on
      an I_T nexus with a pending unit attention condition (i.e., before the
      device server reports CHECK CONDITION status), then the device server
      shall not clear the pending unit attention condition."  Do the
      transport_kmap_data_sg early to detect this case.
      
      It also tells us "Device servers shall not adjust the additional sense
      length to reflect truncation if the allocation length is less than the
      sense data available", so do not do that!  Note that the err variable
      is write-only.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      32a8811f
    • P
      target: support zero-size allocation lengths in transport_kmap_data_sg · 3717ef0c
      Paolo Bonzini 提交于
      In order to support zero-size allocation lengths, do not assert
      that we have a scatterlist until after checking cmd->data_length.
      
      But once we do this, we can have two cases of transport_kmap_data_sg
      returning NULL: a zero-size allocation length, or an out-of-memory
      condition.  Report the latter using sense codes, so that the SCSI
      command that triggered it will fail.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      3717ef0c