1. 10 Feb, 2017 1 commit
  2. 09 Feb, 2017 1 commit
  3. 01 Feb, 2017 2 commits
  4. 24 Jan, 2017 1 commit
  5. 21 Jan, 2017 1 commit
    • Eric Farman's avatar
      scsi: virtio_scsi: Reject commands when virtqueue is broken · 773c7220
      Eric Farman authored
      In the case of a graceful set of detaches, where the virtio-scsi-ccw
      disk is removed from the guest prior to the controller, the guest
      behaves quite normally.  Specifically, the detach gets us into
      sd_sync_cache to issue a Synchronize Cache(10) command, which
      immediately fails (and is retried a couple of times) because the device
      has been removed.  Later, the removal of the controller sees two CRWs
      presented, but there's no further indication of the removal from the
      guest viewpoint.
      
       [   17.217458] sd 0:0:0:0: [sda] Synchronizing SCSI cache
       [   17.219257] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
       [   21.449400] crw_info : CRW reports slct=0, oflw=0, chn=1, rsc=3, anc=0, erc=4, rsid=2
       [   21.449406] crw_info : CRW reports slct=0, oflw=0, chn=0, rsc=3, anc=0, erc=4, rsid=0
      
      However, on s390, the SCSI disks can be removed "by surprise" when an
      entire controller (host) is removed and all associated disks are removed
      via the loop in scsi_forget_host.  The same call to sd_sync_cache is
      made, but because the controller has already been removed, the
      Synchronize Cache(10) command is neither issued (and then failed) nor
      rejected.
      
      That the I/O isn't returned means the guest cannot have other devices
      added nor removed, and other tasks (such as shutdown or reboot) issued
      by the guest will not complete either.  The virtio ring has already been
      marked as broken (via virtio_break_device in virtio_ccw_remove), but we
      still attempt to queue the command only to have it remain there.  The
      calling sequence provides a bit of distinction for us:
      
        virtscsi_queuecommand()
         -> virtscsi_kick_cmd()
          -> virtscsi_add_cmd()
           -> virtqueue_add_sgs()
            -> virtqueue_add()
               if success
                 return 0
               elseif vq->broken or vring_mapping_error()
                 return -EIO
               else
                 return -ENOSPC
      
      A return of ENOSPC is generally a temporary condition, so returning
      "host busy" from virtscsi_queuecommand makes sense here, to have it
      redriven in a moment or two.  But the EIO return code is more of a
      permanent error and so it would be wise to return the I/O itself and
      allow the calling thread to finish gracefully.  The result is these four
      kernel messages in the guest (the fourth one does not occur prior to
      this patch):
      
       [   22.921562] crw_info : CRW reports slct=0, oflw=0, chn=1, rsc=3, anc=0, erc=4, rsid=2
       [   22.921580] crw_info : CRW reports slct=0, oflw=0, chn=0, rsc=3, anc=0, erc=4, rsid=0
       [   22.921978] sd 0:0:0:0: [sda] Synchronizing SCSI cache
       [   22.921993] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
      
      I opted to fill in the same response data that is returned from the more
      graceful device detach, where the disk device is removed prior to the
      controller device.
      Signed-off-by: default avatarEric Farman <farman@linux.vnet.ibm.com>
      Reviewed-by: default avatarFam Zheng <famz@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      773c7220
  6. 17 Jan, 2017 6 commits
  7. 16 Jan, 2017 1 commit
  8. 12 Jan, 2017 3 commits
  9. 10 Jan, 2017 2 commits
    • Dave Jones's avatar
      scsi: qla2xxx: Fix apparent cut-n-paste error. · c3c42394
      Dave Jones authored
      Commit 093df737 ("scsi: qla2xxx: Fix Target mode handling with
      Multiqueue changes.") introduces two bodies of code that look similar
      but with s/req/rsp/ in the second instance.  But in one case, it looks
      like this conversion was missed.
      Signed-off-by: default avatarDave Jones <davej@codemonkey.org.uk>
      Reviewed-by: default avatarLaurence Oberman <loberman@redhat.com>
      Acked-by: default avatarQuinn Tran <Quinn.Tran@cavium.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      c3c42394
    • Milan P. Gandhi's avatar
      scsi: qla2xxx: Get mutex lock before checking optrom_state · c7702b8c
      Milan P. Gandhi authored
      There is a race condition with qla2xxx optrom functions where one thread
      might modify optrom buffer, optrom_state while other thread is still
      reading from it.
      
      In couple of crashes, it was found that we had successfully passed the
      following 'if' check where we confirm optrom_state to be
      QLA_SREADING. But by the time we acquired mutex lock to proceed with
      memory_read_from_buffer function, some other thread/process had already
      modified that option rom buffer and optrom_state from QLA_SREADING to
      QLA_SWAITING. Then we got ha->optrom_buffer 0x0 and crashed the system:
      
              if (ha->optrom_state != QLA_SREADING)
                      return 0;
      
              mutex_lock(&ha->optrom_mutex);
              rval = memory_read_from_buffer(buf, count, &off, ha->optrom_buffer,
                  ha->optrom_region_size);
              mutex_unlock(&ha->optrom_mutex);
      
      With current optrom function we get following crash due to a race
      condition:
      
      [ 1479.466679] BUG: unable to handle kernel NULL pointer dereference at           (null)
      [ 1479.466707] IP: [<ffffffff81326756>] memcpy+0x6/0x110
      [...]
      [ 1479.473673] Call Trace:
      [ 1479.474296]  [<ffffffff81225cbc>] ? memory_read_from_buffer+0x3c/0x60
      [ 1479.474941]  [<ffffffffa01574dc>] qla2x00_sysfs_read_optrom+0x9c/0xc0 [qla2xxx]
      [ 1479.475571]  [<ffffffff8127e76b>] read+0xdb/0x1f0
      [ 1479.476206]  [<ffffffff811fdf9e>] vfs_read+0x9e/0x170
      [ 1479.476839]  [<ffffffff811feb6f>] SyS_read+0x7f/0xe0
      [ 1479.477466]  [<ffffffff816964c9>] system_call_fastpath+0x16/0x1b
      
      Below patch modifies qla2x00_sysfs_read_optrom,
      qla2x00_sysfs_write_optrom functions to get the mutex_lock before
      checking ha->optrom_state to avoid similar crashes.
      
      The patch was applied and tested and same crashes were no longer
      observed again.
      Tested-by: default avatarMilan P. Gandhi <mgandhi@redhat.com>
      Signed-off-by: default avatarMilan P. Gandhi <mgandhi@redhat.com>
      Reviewed-by: default avatarLaurence Oberman <loberman@redhat.com>
      Acked-by: default avatarHimanshu Madhani <himanshu.madhani@cavium.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      c7702b8c
  10. 06 Jan, 2017 3 commits
  11. 20 Dec, 2016 2 commits
  12. 14 Dec, 2016 17 commits
    • Wei Fang's avatar
      scsi: avoid a permanent stop of the scsi device's request queue · d2a14525
      Wei Fang authored
      A race between scanning and fc_remote_port_delete() may result in a
      permanent stop if the device gets blocked before scsi_sysfs_add_sdev()
      and unblocked after.  The reason is that blocking a device sets both the
      SDEV_BLOCKED state and the QUEUE_FLAG_STOPPED.  However,
      scsi_sysfs_add_sdev() unconditionally sets SDEV_RUNNING which causes the
      device to be ignored by scsi_target_unblock() and thus never have its
      QUEUE_FLAG_STOPPED cleared leading to a device which is apparently
      running but has a stopped queue.
      
      We actually have two places where SDEV_RUNNING is set: once in
      scsi_add_lun() which respects the blocked flag and once in
      scsi_sysfs_add_sdev() which doesn't.  Since the second set is entirely
      spurious, simply remove it to fix the problem.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarZengxi Chen <chenzengxi@huawei.com>
      Signed-off-by: default avatarWei Fang <fangwei1@huawei.com>
      Reviewed-by: default avatarEwan D. Milne <emilne@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      d2a14525
    • Adam Manzanares's avatar
      scsi: mpt3sas: Recognize and act on iopriority info · 307d9075
      Adam Manzanares authored
      This patch adds support for request iopriority handling in the mpt3sas
      layer. This works only when a ATA device is behind the SATL. The ATA
      device also has to indicate that it supports command priorities in the
      identify information that is pulled from the SATL.
      Signed-off-by: default avatarAdam Manzanares <adam.manzanares@wdc.com>
      Acked-by: default avatarSreekanth Reddy <Sreekanth.Reddy@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      307d9075
    • Quinn Tran's avatar
      scsi: qla2xxx: Fix Target mode handling with Multiqueue changes. · 093df737
      Quinn Tran authored
      - Fix race condition between dpc_thread accessing Multiqueue resources
        and qla2x00_remove_one thread trying to free resource.
      - Fix out of order free for Multiqueue resources. Also, Multiqueue
        interrupts needs a workqueue. Interrupt needed to stop before
        the wq can be destroyed.
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarQuinn Tran <quinn.tran@cavium.com>
      Signed-off-by: default avatarHimanshu Madhani <himanshu.madhani@cavium.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      093df737
    • Michael Hernandez's avatar
      scsi: qla2xxx: Add Block Multi Queue functionality. · 5601236b
      Michael Hernandez authored
      Tell the SCSI layer how many hardware queues we have based on the number
      of max queue pairs created. The number of max queue pairs created will
      depend on number of MSI-X vector count.
      
      This feature can be turned on via CONFIG_SCSI_MQ_DEFAULT or passing
      scsi_mod.use_blk_mq=Y as a parameter to the kernel
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarSawan Chandak <sawan.chandak@cavium.com>
      Signed-off-by: default avatarMichael Hernandez <michael.hernandez@cavium.com>
      Signed-off-by: default avatarHimanshu Madhani <himanshu.madhani@cavium.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      5601236b
    • Michael Hernandez's avatar
      scsi: qla2xxx: Add multiple queue pair functionality. · d7459527
      Michael Hernandez authored
      Replaced existing multiple queue functionality with framework
      that allows for the creation of pairs of request and response queues,
      either at start of day or dynamically.
      
      Queue pair creation depend on module parameter "ql2xmqsupport",
      which need to be enabled to create queue pair.
      Signed-off-by: default avatarSawan Chandak <sawan.chandak@cavium.com>
      Signed-off-by: default avatarMichael Hernandez <michael.hernandez@cavium.com>
      Signed-off-by: default avatarHimanshu Madhani <himanshu.madhani@cavium.com>
      Acked-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      d7459527
    • Michael Hernandez's avatar
      scsi: qla2xxx: Utilize pci_alloc_irq_vectors/pci_free_irq_vectors calls. · 4fa18345
      Michael Hernandez authored
      Replaces the old pci_enable_msi[x]* and pci_disable_msi[x] calls.
      Signed-off-by: default avatarMichael Hernandez <michael.hernandez@cavium.com>
      Signed-off-by: default avatarHimanshu Madhani <himanshu.madhani@cavium.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      4fa18345
    • himanshu.madhani@cavium.com's avatar
      scsi: qla2xxx: Only allow operational MBX to proceed during RESET. · 77ddb94a
      himanshu.madhani@cavium.com authored
      This patch is allowing only ROM mailbox command which are
      necessary to initialize chip after a reset has been issued.
      In a target environment, there could be a user space daemon
      which can issue statistics and other management mailbox command
      which are non-critical. This patch will timeout non critical
      mailbox commands immediately rather than waiting for timeout,
      if driver detects that chip reset has been issued or chip reset
      is in progress.
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@infradead.org>
      Signed-off-by: default avatarHimanshu Madhani <himanshu.madhani@cavium.com>
      Signed-off-by: default avatarGiridhar Malavali <giridhar.malavali@cavium.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      77ddb94a
    • Amit Kushwaha's avatar
      scsi: hpsa: remove memory allocate failure message · 7e8a9486
      Amit Kushwaha authored
      This patch cleanup warning reported by checkpatch.pl WARNING: Possible
      unnecessary 'out of memory' message With no available memory, a warn on
      message already gets printed by page alloc apis and modified goto use if
      memory unallocated.
      Signed-off-by: default avatarAmit Kushwaha <kushwaha.a@samsung.com>
      Acked-by: default avatarDon Brace <don.brace@microsemi.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      7e8a9486
    • adam radford's avatar
      scsi: Update 3ware driver email addresses · 2c9bce5b
      adam radford authored
      This change updates the 3ware drivers (3w-xxxx, 3w-9xxx, 3w-sas) email
      addresses from linuxraid@lsi.com to aradford@gmail.com, since the old
      email address doesn't exist.
      
      This patch was updated to remove www.lsi.com text.
      
      [mkp: applied by hand]
      Signed-off-by: default avatarAdam Radford <aradford@gmail.com>
      Acked-by: default avatarSumit Saxena <sumit.saxena@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      2c9bce5b
    • Steffen Maier's avatar
      scsi: zfcp: fix rport unblock race with LUN recovery · 6f2ce1c6
      Steffen Maier authored
      It is unavoidable that zfcp_scsi_queuecommand() has to finish requests
      with DID_IMM_RETRY (like fc_remote_port_chkready()) during the time
      window when zfcp detected an unavailable rport but
      fc_remote_port_delete(), which is asynchronous via
      zfcp_scsi_schedule_rport_block(), has not yet blocked the rport.
      
      However, for the case when the rport becomes available again, we should
      prevent unblocking the rport too early.  In contrast to other FCP LLDDs,
      zfcp has to open each LUN with the FCP channel hardware before it can
      send I/O to a LUN.  So if a port already has LUNs attached and we
      unblock the rport just after port recovery, recoveries of LUNs behind
      this port can still be pending which in turn force
      zfcp_scsi_queuecommand() to unnecessarily finish requests with
      DID_IMM_RETRY.
      
      This also opens a time window with unblocked rport (until the followup
      LUN reopen recovery has finished).  If a scsi_cmnd timeout occurs during
      this time window fc_timed_out() cannot work as desired and such command
      would indeed time out and trigger scsi_eh. This prevents a clean and
      timely path failover.  This should not happen if the path issue can be
      recovered on FC transport layer such as path issues involving RSCNs.
      
      Fix this by only calling zfcp_scsi_schedule_rport_register(), to
      asynchronously trigger fc_remote_port_add(), after all LUN recoveries as
      children of the rport have finished and no new recoveries of equal or
      higher order were triggered meanwhile.  Finished intentionally includes
      any recovery result no matter if successful or failed (still unblock
      rport so other successful LUNs work).  For simplicity, we check after
      each finished LUN recovery if there is another LUN recovery pending on
      the same port and then do nothing.  We handle the special case of a
      successful recovery of a port without LUN children the same way without
      changing this case's semantics.
      
      For debugging we introduce 2 new trace records written if the rport
      unblock attempt was aborted due to still unfinished or freshly triggered
      recovery. The records are only written above the default trace level.
      
      Benjamin noticed the important special case of new recovery that can be
      triggered between having given up the erp_lock and before calling
      zfcp_erp_action_cleanup() within zfcp_erp_strategy().  We must avoid the
      following sequence:
      
      ERP thread                 rport_work      other context
      -------------------------  --------------  --------------------------------
      port is unblocked, rport still blocked,
       due to pending/running ERP action,
       so ((port->status & ...UNBLOCK) != 0)
       and (port->rport == NULL)
      unlock ERP
      zfcp_erp_action_cleanup()
      case ZFCP_ERP_ACTION_REOPEN_LUN:
      zfcp_erp_try_rport_unblock()
      ((status & ...UNBLOCK) != 0) [OLD!]
                                                 zfcp_erp_port_reopen()
                                                 lock ERP
                                                 zfcp_erp_port_block()
                                                 port->status clear ...UNBLOCK
                                                 unlock ERP
                                                 zfcp_scsi_schedule_rport_block()
                                                 port->rport_task = RPORT_DEL
                                                 queue_work(rport_work)
                                 zfcp_scsi_rport_work()
                                 (port->rport_task != RPORT_ADD)
                                 port->rport_task = RPORT_NONE
                                 zfcp_scsi_rport_block()
                                 if (!port->rport) return
      zfcp_scsi_schedule_rport_register()
      port->rport_task = RPORT_ADD
      queue_work(rport_work)
                                 zfcp_scsi_rport_work()
                                 (port->rport_task == RPORT_ADD)
                                 port->rport_task = RPORT_NONE
                                 zfcp_scsi_rport_register()
                                 (port->rport == NULL)
                                 rport = fc_remote_port_add()
                                 port->rport = rport;
      
      Now the rport was erroneously unblocked while the zfcp_port is blocked.
      This is another situation we want to avoid due to scsi_eh
      potential. This state would at least remain until the new recovery from
      the other context finished successfully, or potentially forever if it
      failed.  In order to close this race, we take the erp_lock inside
      zfcp_erp_try_rport_unblock() when checking the status of zfcp_port or
      LUN.  With that, the possible corresponding rport state sequences would
      be: (unblock[ERP thread],block[other context]) if the ERP thread gets
      erp_lock first and still sees ((port->status & ...UNBLOCK) != 0),
      (block[other context],NOP[ERP thread]) if the ERP thread gets erp_lock
      after the other context has already cleard ...UNBLOCK from port->status.
      
      Since checking fields of struct erp_action is unsafe because they could
      have been overwritten (re-used for new recovery) meanwhile, we only
      check status of zfcp_port and LUN since these are only changed under
      erp_lock elsewhere. Regarding the check of the proper status flags (port
      or port_forced are similar to the shown adapter recovery):
      
      [zfcp_erp_adapter_shutdown()]
      zfcp_erp_adapter_reopen()
       zfcp_erp_adapter_block()
        * clear UNBLOCK ---------------------------------------+
       zfcp_scsi_schedule_rports_block()                       |
       write_lock_irqsave(&adapter->erp_lock, flags);-------+  |
       zfcp_erp_action_enqueue()                            |  |
        zfcp_erp_setup_act()                                |  |
         * set ERP_INUSE -----------------------------------|--|--+
       write_unlock_irqrestore(&adapter->erp_lock, flags);--+  |  |
      .context-switch.                                         |  |
      zfcp_erp_thread()                                        |  |
       zfcp_erp_strategy()                                     |  |
        write_lock_irqsave(&adapter->erp_lock, flags);------+  |  |
        ...                                                 |  |  |
        zfcp_erp_strategy_check_target()                    |  |  |
         zfcp_erp_strategy_check_adapter()                  |  |  |
          zfcp_erp_adapter_unblock()                        |  |  |
           * set UNBLOCK -----------------------------------|--+  |
        zfcp_erp_action_dequeue()                           |     |
         * clear ERP_INUSE ---------------------------------|-----+
        ...                                                 |
        write_unlock_irqrestore(&adapter->erp_lock, flags);-+
      
      Hence, we should check for both UNBLOCK and ERP_INUSE because they are
      interleaved.  Also we need to explicitly check ERP_FAILED for the link
      down case which currently does not clear the UNBLOCK flag in
      zfcp_fsf_link_down_info_eval().
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: 8830271c ("[SCSI] zfcp: Dont fail SCSI commands when transitioning to blocked fc_rport")
      Fixes: a2fa0aed ("[SCSI] zfcp: Block FC transport rports early on errors")
      Fixes: 5f852be9 ("[SCSI] zfcp: Fix deadlock between zfcp ERP and SCSI")
      Fixes: 338151e0 ("[SCSI] zfcp: make use of fc_remote_port_delete when target port is unavailable")
      Fixes: 3859f6a2 ("[PATCH] zfcp: add rports to enable scsi_add_device to work again")
      Cc: <stable@vger.kernel.org> #2.6.32+
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      6f2ce1c6
    • Steffen Maier's avatar
      scsi: zfcp: do not trace pure benign residual HBA responses at default level · 56d23ed7
      Steffen Maier authored
      Since quite a while, Linux issues enough SCSI commands per scsi_device
      which successfully return with FCP_RESID_UNDER, FSF_FCP_RSP_AVAILABLE,
      and SAM_STAT_GOOD.  This floods the HBA trace area and we cannot see
      other and important HBA trace records long enough.
      
      Therefore, do not trace HBA response errors for pure benign residual
      under counts at the default trace level.
      
      This excludes benign residual under count combined with other validity
      bits set in FCP_RSP_IU, such as FCP_SNS_LEN_VAL.  For all those other
      cases, we still do want to see both the HBA record and the corresponding
      SCSI record by default.
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: a54ca0f6 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
      Cc: <stable@vger.kernel.org> #2.6.37+
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      56d23ed7
    • Benjamin Block's avatar
      scsi: zfcp: fix use-after-"free" in FC ingress path after TMF · dac37e15
      Benjamin Block authored
      When SCSI EH invokes zFCP's callbacks for eh_device_reset_handler() and
      eh_target_reset_handler(), it expects us to relent the ownership over
      the given scsi_cmnd and all other scsi_cmnds within the same scope - LUN
      or target - when returning with SUCCESS from the callback ('release'
      them).  SCSI EH can then reuse those commands.
      
      We did not follow this rule to release commands upon SUCCESS; and if
      later a reply arrived for one of those supposed to be released commands,
      we would still make use of the scsi_cmnd in our ingress tasklet. This
      will at least result in undefined behavior or a kernel panic because of
      a wrong kernel pointer dereference.
      
      To fix this, we NULLify all pointers to scsi_cmnds (struct zfcp_fsf_req
      *)->data in the matching scope if a TMF was successful. This is done
      under the locks (struct zfcp_adapter *)->abort_lock and (struct
      zfcp_reqlist *)->lock to prevent the requests from being removed from
      the request-hashtable, and the ingress tasklet from making use of the
      scsi_cmnd-pointer in zfcp_fsf_fcp_cmnd_handler().
      
      For cases where a reply arrives during SCSI EH, but before we get a
      chance to NULLify the pointer - but before we return from the callback
      -, we assume that the code is protected from races via the CAS operation
      in blk_complete_request() that is called in scsi_done().
      
      The following stacktrace shows an example for a crash resulting from the
      previous behavior:
      
      Unable to handle kernel pointer dereference at virtual kernel address fffffee17a672000
      Oops: 0038 [#1] SMP
      CPU: 2 PID: 0 Comm: swapper/2 Not tainted
      task: 00000003f7ff5be0 ti: 00000003f3d38000 task.ti: 00000003f3d38000
      Krnl PSW : 0404d00180000000 00000000001156b0 (smp_vcpu_scheduled+0x18/0x40)
                 R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
      Krnl GPRS: 000000200000007e 0000000000000000 fffffee17a671fd8 0000000300000015
                 ffffffff80000000 00000000005dfde8 07000003f7f80e00 000000004fa4e800
                 000000036ce8d8f8 000000036ce8d9c0 00000003ece8fe00 ffffffff969c9e93
                 00000003fffffffd 000000036ce8da10 00000000003bf134 00000003f3b07918
      Krnl Code: 00000000001156a2: a7190000        lghi    %r1,0
                 00000000001156a6: a7380015        lhi    %r3,21
                #00000000001156aa: e32050000008    ag    %r2,0(%r5)
                >00000000001156b0: 482022b0        lh    %r2,688(%r2)
                 00000000001156b4: ae123000        sigp    %r1,%r2,0(%r3)
                 00000000001156b8: b2220020        ipm    %r2
                 00000000001156bc: 8820001c        srl    %r2,28
                 00000000001156c0: c02700000001    xilf    %r2,1
      Call Trace:
      ([<0000000000000000>] 0x0)
       [<000003ff807bdb8e>] zfcp_fsf_fcp_cmnd_handler+0x3de/0x490 [zfcp]
       [<000003ff807be30a>] zfcp_fsf_req_complete+0x252/0x800 [zfcp]
       [<000003ff807c0a48>] zfcp_fsf_reqid_check+0xe8/0x190 [zfcp]
       [<000003ff807c194e>] zfcp_qdio_int_resp+0x66/0x188 [zfcp]
       [<000003ff80440c64>] qdio_kick_handler+0xdc/0x310 [qdio]
       [<000003ff804463d0>] __tiqdio_inbound_processing+0xf8/0xcd8 [qdio]
       [<0000000000141fd4>] tasklet_action+0x9c/0x170
       [<0000000000141550>] __do_softirq+0xe8/0x258
       [<000000000010ce0a>] do_softirq+0xba/0xc0
       [<000000000014187c>] irq_exit+0xc4/0xe8
       [<000000000046b526>] do_IRQ+0x146/0x1d8
       [<00000000005d6a3c>] io_return+0x0/0x8
       [<00000000005d6422>] vtime_stop_cpu+0x4a/0xa0
      ([<0000000000000000>] 0x0)
       [<0000000000103d8a>] arch_cpu_idle+0xa2/0xb0
       [<0000000000197f94>] cpu_startup_entry+0x13c/0x1f8
       [<0000000000114782>] smp_start_secondary+0xda/0xe8
       [<00000000005d6efe>] restart_int_handler+0x56/0x6c
       [<0000000000000000>] 0x0
      Last Breaking-Event-Address:
       [<00000000003bf12e>] arch_spin_lock_wait+0x56/0xb0
      Suggested-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Fixes: ea127f97 ("[PATCH] s390 (7/7): zfcp host adapter.") (tglx/history.git)
      Cc: <stable@vger.kernel.org> #2.6.32+
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      dac37e15
    • Varun Prakash's avatar
      scsi: libcxgbi: return error if interface is not up · 165ae50e
      Varun Prakash authored
      Do not post hw active open cmd if IFF_UP is not set or link is down on
      the interface, return -ENETDOWN in this case.
      Signed-off-by: default avatarVarun Prakash <varun@chelsio.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      165ae50e
    • Varun Prakash's avatar
      scsi: cxgb4i: libcxgbi: add missing module_put() · 1fe1fdb0
      Varun Prakash authored
      Add module_put() in cxgbi_sock_act_open_req_arp_failure() to release
      module reference in case of arp failure, also check return value of
      try_module_get() before posting active open hw cmd.
      Signed-off-by: default avatarVarun Prakash <varun@chelsio.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      1fe1fdb0
    • Varun Prakash's avatar
      scsi: cxgb4i: libcxgbi: cxgb4: add T6 iSCSI completion feature · 44830d8f
      Varun Prakash authored
      T6 adapters reduce number of completions to host by generating single
      completion for all the directly placed(DDP) iSCSI pdus in a sequence.
      
      This patch adds new structure for completion hw cmd (struct
      cpl_rx_iscsi_cmp) and implements T6 completion feature.
      Signed-off-by: default avatarVarun Prakash <varun@chelsio.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      44830d8f
    • Varun Prakash's avatar
      scsi: cxgb4i: libcxgbi: add active open cmd for T6 adapters · 586be7cb
      Varun Prakash authored
      Add T6 active open cmd to open active connections on T6 adapters.
      Signed-off-by: default avatarVarun Prakash <varun@chelsio.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      586be7cb
    • Varun Prakash's avatar
      scsi: cxgb4i: use cxgb4_tp_smt_idx() to get smt_idx · e0eed8ab
      Varun Prakash authored
      cxgb4_tp_smt_idx() is defined in cxgb4 driver, it returns smt_idx for
      T4,T5,T6 adapters.
      Signed-off-by: default avatarVarun Prakash <varun@chelsio.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      e0eed8ab