1. 22 3月, 2012 5 次提交
  2. 16 3月, 2012 9 次提交
  3. 15 3月, 2012 5 次提交
  4. 14 3月, 2012 2 次提交
    • N
      iscsi-target: Fix reservation conflict -EBUSY response handling bug · 00fdc6bb
      Nicholas Bellinger 提交于
      This patch addresses a iscsi-target specific bug related to reservation conflict
      handling in iscsit_handle_scsi_cmd() that has been causing reservation conflicts
      to complete and not fail as expected due to incorrect errno checking.  The problem
      occured with the change to return -EBUSY from transport_generic_cmd_sequencer() ->
      transport_generic_allocate_tasks() failures, that broke iscsit_handle_scsi_cmd()
      checking for -EINVAL in order to invoke a non GOOD status response.
      
      This was manifesting itself as data corruption with legacy SPC-2 reservations,
      but also effects iscsi-target LUNs with SPC-3 persistent reservations.
      
      This bug was originally introduced in lio-core commit:
      
      commit 03e98c9e
      Author: Nicholas Bellinger <nab@linux-iscsi.org>
      Date:   Fri Nov 4 02:36:16 2011 -0700
      
          target: Address legacy PYX_TRANSPORT_* return code breakage
      Reported-by: NMartin Svec <martin.svec@zoner.cz>
      Cc: Martin Svec <martin.svec@zoner.cz>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      00fdc6bb
    • N
      target: Fix compatible reservation handling (CRH=1) with legacy RESERVE/RELEASE · 087a03b3
      Nicholas Bellinger 提交于
      This patch addresses a bug with target_check_scsi2_reservation_conflict()
      return checking in target_scsi2_reservation_[reserve,release]() that was
      preventing CRH=1 operation from silently succeeding in the two special
      cases defined by SPC-3, and not failing with reservation conflict status
      when dealing with legacy RESERVE/RELEASE + active SPC-3 PR logic.
      
      Also explictly set cmd->scsi_status = SAM_STAT_RESERVATION_CONFLICT during
      the early non reservation holder failure from pr_ops->t10_seq_non_holder()
      check in transport_generic_cmd_sequencer() for fabrics that already expect
      it to be set.
      
      This bug was originally introduced in mainline commit:
      
      commit eacac00c
      Author: Christoph Hellwig <hch@infradead.org>
      Date:   Thu Nov 3 17:50:40 2011 -0400
      
          target: split core_scsi2_emulate_crh
      Reported-by: NMartin Svec <martin.svec@zoner.cz>
      Cc: Martin Svec <martin.svec@zoner.cz>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      087a03b3
  5. 13 3月, 2012 10 次提交
  6. 12 3月, 2012 8 次提交
  7. 09 3月, 2012 1 次提交
    • R
      sh-sci / PM: Avoid deadlocking runtime PM · 048be431
      Rafael J. Wysocki 提交于
      The runtime PM of sh-sci devices is enabled when sci_probe() returns,
      so the pm_runtime_put_sync() executed by driver_probe_device()
      attempts to suspend the device.  Then, in some situations, a
      diagnostic message is printed to the console by one of the runtime
      suspend routines handling the sh-sci device, which causes synchronous
      runtime resume to be started from the device's own runtime suspend
      callback.  This causes rpm_resume() to be run eventually, which sees
      the RPM_SUSPENDING status set by rpm_suspend() and waits for it to
      change.  However, the device's runtime PM status cannot change at
      that point, because the routine that has set it waits for the
      rpm_suspend() to return.  A deadlock occurs as a result.
      
      To avoid that make sci_init_single() increment the device's
      runtime PM usage counter, so that it cannot be suspended by
      driver_probe_device().  That counter has to be decremented
      eventually, so make sci_startup() do that before starting to
      actually use the device and make sci_shutdown() increment it
      again before returning to balance the incrementation carried out by
      sci_startup().
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Tested-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      048be431