1. 19 Jun, 2019 4 commits
    • Arun Easi's avatar
      scsi: qla2xxx: Fix hardlockup in abort command during driver remove · 5589b08e
      Arun Easi authored
      [436194.555537] NMI watchdog: Watchdog detected hard LOCKUP on cpu 5
      [436194.555558] RIP: 0010:native_queued_spin_lock_slowpath+0x63/0x1e0
      
      [436194.555563] Call Trace:
      [436194.555564]  _raw_spin_lock_irqsave+0x30/0x40
      [436194.555564]  qla24xx_async_abort_command+0x29/0xd0 [qla2xxx]
      [436194.555565]  qla24xx_abort_command+0x208/0x2d0 [qla2xxx]
      [436194.555565]  __qla2x00_abort_all_cmds+0x16b/0x290 [qla2xxx]
      [436194.555565]  qla2x00_abort_all_cmds+0x42/0x60 [qla2xxx]
      [436194.555566]  qla2x00_abort_isp_cleanup+0x2bd/0x3a0 [qla2xxx]
      [436194.555566]  qla2x00_remove_one+0x1ad/0x360 [qla2xxx]
      [436194.555566]  pci_device_remove+0x3b/0xb0
      
      Fixes: 219d27d7 (scsi: qla2xxx: Fix race conditions in the code for aborting SCSI commands)
      Cc: stable@vger.kernel.org # 5.2
      Signed-off-by: default avatarArun Easi <aeasi@marvell.com>
      Signed-off-by: default avatarHimanshu Madhani <hmadhani@marvell.com>
      Reviewed-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      5589b08e
    • Stanley Chu's avatar
      scsi: ufs: Avoid runtime suspend possibly being blocked forever · 24e2e7a1
      Stanley Chu authored
      UFS runtime suspend can be triggered after pm_runtime_enable() is invoked
      in ufshcd_pltfrm_init(). However if the first runtime suspend is triggered
      before binding ufs_hba structure to ufs device structure via
      platform_set_drvdata(), then UFS runtime suspend will be no longer
      triggered in the future because its dev->power.runtime_error was set in the
      first triggering and does not have any chance to be cleared.
      
      To be more clear, dev->power.runtime_error is set if hba is NULL in
      ufshcd_runtime_suspend() which returns -EINVAL to rpm_callback() where
      dev->power.runtime_error is set as -EINVAL. In this case, any future
      rpm_suspend() for UFS device fails because rpm_check_suspend_allowed()
      fails due to non-zero
      dev->power.runtime_error.
      
      To resolve this issue, make sure the first UFS runtime suspend get valid
      "hba" in ufshcd_runtime_suspend(): Enable UFS runtime PM only after hba is
      successfully bound to UFS device structure.
      
      Fixes: 62694735 ([SCSI] ufs: Add runtime PM support for UFS host controller driver)
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarStanley Chu <stanley.chu@mediatek.com>
      Reviewed-by: default avatarAvri Altman <avri.altman@wdc.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      24e2e7a1
    • Nilesh Javali's avatar
      scsi: qedi: update driver version to 8.37.0.20 · 8cf4c540
      Nilesh Javali authored
      Update qedi driver version to 8.37.0.20
      Signed-off-by: default avatarNilesh Javali <njavali@marvell.com>
      Reviewed-by: default avatarLee Duncan <lduncan@suse.com>
      Reviewed-by: default avatarChris Leech <cleech@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      8cf4c540
    • Nilesh Javali's avatar
      scsi: qedi: Check targetname while finding boot target information · 1ac3549e
      Nilesh Javali authored
      The kernel panic was observed during iSCSI discovery via offload with below
      call trace,
      
      [ 2115.646901] BUG: unable to handle kernel NULL pointer dereference at (null)
      [ 2115.646909] IP: [<ffffffffacf7f0cc>] strncmp+0xc/0x60
      [ 2115.646927] PGD 0
      [ 2115.646932] Oops: 0000 [#1] SMP
      [ 2115.647107] CPU: 24 PID: 264 Comm: kworker/24:1 Kdump: loaded Tainted: G
                     OE  ------------   3.10.0-957.el7.x86_64 #1
      [ 2115.647133] Workqueue: slowpath-13:00. qed_slowpath_task [qed]
      [ 2115.647135] task: ffff8d66af80b0c0 ti: ffff8d66afb80000 task.ti: ffff8d66afb80000
      [ 2115.647136] RIP: 0010:[<ffffffffacf7f0cc>]  [<ffffffffacf7f0cc>] strncmp+0xc/0x60
      [ 2115.647141] RSP: 0018:ffff8d66afb83c68  EFLAGS: 00010206
      [ 2115.647143] RAX: 0000000000000001 RBX: 0000000000000007 RCX: 000000000000000a
      [ 2115.647144] RDX: 0000000000000100 RSI: 0000000000000000 RDI: ffff8d632b3ba040
      [ 2115.647145] RBP: ffff8d66afb83c68 R08: 0000000000000000 R09: 000000000000ffff
      [ 2115.647147] R10: 0000000000000007 R11: 0000000000000800 R12: ffff8d66a30007a0
      [ 2115.647148] R13: ffff8d66747a3c10 R14: ffff8d632b3ba000 R15: ffff8d66747a32f8
      [ 2115.647149] FS:  0000000000000000(0000) GS:ffff8d66aff00000(0000) knlGS:0000000000000000
      [ 2115.647151] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 2115.647152] CR2: 0000000000000000 CR3: 0000000509610000 CR4: 00000000007607e0
      [ 2115.647153] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 2115.647154] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [ 2115.647155] PKRU: 00000000
      [ 2115.647157] Call Trace:
      [ 2115.647165]  [<ffffffffc0634cc5>] qedi_get_protocol_tlv_data+0x2c5/0x510 [qedi]
      [ 2115.647184]  [<ffffffffc05968f5>] ? qed_mfw_process_tlv_req+0x245/0xbe0 [qed]
      [ 2115.647195]  [<ffffffffc05496cb>] qed_mfw_fill_tlv_data+0x4b/0xb0 [qed]
      [ 2115.647206]  [<ffffffffc0596911>] qed_mfw_process_tlv_req+0x261/0xbe0 [qed]
      [ 2115.647215]  [<ffffffffacce0e8e>] ? dequeue_task_fair+0x41e/0x660
      [ 2115.647221]  [<ffffffffacc2a59e>] ? __switch_to+0xce/0x580
      [ 2115.647230]  [<ffffffffc0546013>] qed_slowpath_task+0xa3/0x160 [qed]
      [ 2115.647278] RIP  [<ffffffffacf7f0cc>] strncmp+0xc/0x60
      
      Fix kernel panic by validating the session targetname before providing TLV
      data and confirming the presence of boot targets.
      Signed-off-by: default avatarNilesh Javali <njavali@marvell.com>
      Reviewed-by: default avatarLee Duncan <lduncan@suse.com>
      Reviewed-by: default avatarChris Leech <cleech@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      1ac3549e
  2. 07 Jun, 2019 1 commit
  3. 05 Jun, 2019 2 commits
  4. 30 May, 2019 7 commits
    • Jason Yan's avatar
      scsi: libsas: delete sas port if expander discover failed · 3b054179
      Jason Yan authored
      The sas_port(phy->port) allocated in sas_ex_discover_expander() will not be
      deleted when the expander failed to discover. This will cause resource leak
      and a further issue of kernel BUG like below:
      
      [159785.843156]  port-2:17:29: trying to add phy phy-2:17:29 fails: it's
      already part of another port
      [159785.852144] ------------[ cut here  ]------------
      [159785.856833] kernel BUG at drivers/scsi/scsi_transport_sas.c:1086!
      [159785.863000] Internal error: Oops - BUG: 0 [#1] SMP
      [159785.867866] CPU: 39 PID: 16993 Comm: kworker/u96:2 Tainted: G
      W  OE     4.19.25-vhulk1901.1.0.h111.aarch64 #1
      [159785.878458] Hardware name: Huawei Technologies Co., Ltd.
      Hi1620EVBCS/Hi1620EVBCS, BIOS Hi1620 CS B070 1P TA 03/21/2019
      [159785.889231] Workqueue: 0000:74:02.0_disco_q sas_discover_domain
      [159785.895224] pstate: 40c00009 (nZcv daif +PAN +UAO)
      [159785.900094] pc : sas_port_add_phy+0x188/0x1b8
      [159785.904524] lr : sas_port_add_phy+0x188/0x1b8
      [159785.908952] sp : ffff0001120e3b80
      [159785.912341] x29: ffff0001120e3b80 x28: 0000000000000000
      [159785.917727] x27: ffff802ade8f5400 x26: ffff0000681b7560
      [159785.923111] x25: ffff802adf11a800 x24: ffff0000680e8000
      [159785.928496] x23: ffff802ade8f5728 x22: ffff802ade8f5708
      [159785.933880] x21: ffff802adea2db40 x20: ffff802ade8f5400
      [159785.939264] x19: ffff802adea2d800 x18: 0000000000000010
      [159785.944649] x17: 00000000821bf734 x16: ffff00006714faa0
      [159785.950033] x15: ffff0000e8ab4ecf x14: 7261702079646165
      [159785.955417] x13: 726c612073277469 x12: ffff00006887b830
      [159785.960802] x11: ffff00006773eaa0 x10: 7968702079687020
      [159785.966186] x9 : 0000000000002453 x8 : 726f702072656874
      [159785.971570] x7 : 6f6e6120666f2074 x6 : ffff802bcfb21290
      [159785.976955] x5 : ffff802bcfb21290 x4 : 0000000000000000
      [159785.982339] x3 : ffff802bcfb298c8 x2 : 337752b234c2ab00
      [159785.987723] x1 : 337752b234c2ab00 x0 : 0000000000000000
      [159785.993108] Process kworker/u96:2 (pid: 16993, stack limit =
      0x0000000072dae094)
      [159786.000576] Call trace:
      [159786.003097]  sas_port_add_phy+0x188/0x1b8
      [159786.007179]  sas_ex_get_linkrate.isra.5+0x134/0x140
      [159786.012130]  sas_ex_discover_expander+0x128/0x408
      [159786.016906]  sas_ex_discover_dev+0x218/0x4c8
      [159786.021249]  sas_ex_discover_devices+0x9c/0x1a8
      [159786.025852]  sas_discover_root_expander+0x134/0x160
      [159786.030802]  sas_discover_domain+0x1b8/0x1e8
      [159786.035148]  process_one_work+0x1b4/0x3f8
      [159786.039230]  worker_thread+0x54/0x470
      [159786.042967]  kthread+0x134/0x138
      [159786.046269]  ret_from_fork+0x10/0x18
      [159786.049918] Code: 91322300 f0004402 91178042 97fe4c9b (d4210000)
      [159786.056083] Modules linked in: hns3_enet_ut(OE) hclge(OE) hnae3(OE)
      hisi_sas_test_hw(OE) hisi_sas_test_main(OE) serdes(OE)
      [159786.067202] ---[ end trace 03622b9e2d99e196  ]---
      [159786.071893] Kernel panic - not syncing: Fatal exception
      [159786.077190] SMP: stopping secondary CPUs
      [159786.081192] Kernel Offset: disabled
      [159786.084753] CPU features: 0x2,a2a00a38
      
      Fixes: 2908d778 ("[SCSI] aic94xx: new driver")
      Reported-by: default avatarJian Luo <luojian5@huawei.com>
      Signed-off-by: default avatarJason Yan <yanaijie@huawei.com>
      CC: John Garry <john.garry@huawei.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      3b054179
    • Jason Yan's avatar
      scsi: libsas: only clear phy->in_shutdown after shutdown event done · 04cf8b32
      Jason Yan authored
      When the event queue is full of phy up and down events and reached the
      threshold, we will queue a shutdown-event, and set phy->in_shutdown so that
      we will not queue a shutdown-event again. But before the shutdown-event can
      be executed, every phy-down event will clear
      phy->in_shutdown and a new shutdown-event will be queued. The queue will
      be full of these shutdown-events.
      
      Fix this by only clear phy->in_shutdown in sas_phye_shutdown(), that is
      after the first shutdown-event has been executed.
      
      Fixes: f12486e0 ("scsi: libsas: shut down the PHY if events reached the threshold")
      Signed-off-by: default avatarJason Yan <yanaijie@huawei.com>
      CC: John Garry <john.garry@huawei.com>
      CC: Johannes Thumshirn <jthumshirn@suse.de>
      CC: Ewan Milne <emilne@redhat.com>
      CC: Christoph Hellwig <hch@lst.de>
      CC: Tomas Henzl <thenzl@redhat.com>
      CC: Dan Williams <dan.j.williams@intel.com>
      CC: Hannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      04cf8b32
    • YueHaibing's avatar
      scsi: scsi_dh_alua: Fix possible null-ptr-deref · 12e750bc
      YueHaibing authored
      If alloc_workqueue fails in alua_init, it should return -ENOMEM, otherwise
      it will trigger null-ptr-deref while unloading module which calls
      destroy_workqueue dereference
      wq->lock like this:
      
      BUG: KASAN: null-ptr-deref in __lock_acquire+0x6b4/0x1ee0
      Read of size 8 at addr 0000000000000080 by task syz-executor.0/7045
      
      CPU: 0 PID: 7045 Comm: syz-executor.0 Tainted: G         C        5.1.0+ #28
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1
      Call Trace:
       dump_stack+0xa9/0x10e
       __kasan_report+0x171/0x18d
       ? __lock_acquire+0x6b4/0x1ee0
       kasan_report+0xe/0x20
       __lock_acquire+0x6b4/0x1ee0
       lock_acquire+0xb4/0x1b0
       __mutex_lock+0xd8/0xb90
       drain_workqueue+0x25/0x290
       destroy_workqueue+0x1f/0x3f0
       __x64_sys_delete_module+0x244/0x330
       do_syscall_64+0x72/0x2a0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: 03197b61 ("scsi_dh_alua: Use workqueue for RTPG")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Reviewed-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      12e750bc
    • Lianbo Jiang's avatar
      scsi: smartpqi: properly set both the DMA mask and the coherent DMA mask · 1d94f06e
      Lianbo Jiang authored
      When SME is enabled, the smartpqi driver won't work on the HP DL385 G10
      machine, which causes the failure of kernel boot because it fails to
      allocate pqi error buffer. Please refer to the kernel log:
      ....
      [    9.431749] usbcore: registered new interface driver uas
      [    9.441524] Microsemi PQI Driver (v1.1.4-130)
      [    9.442956] i40e 0000:04:00.0: fw 6.70.48768 api 1.7 nvm 10.2.5
      [    9.447237] smartpqi 0000:23:00.0: Microsemi Smart Family Controller found
               Starting dracut initqueue hook...
      [  OK  ] Started Show Plymouth Boot Scre[    9.471654] Broadcom NetXtreme-C/E driver bnxt_en v1.9.1
      en.
      [  OK  ] Started Forward Password Requests to Plymouth Directory Watch.
      [[0;[    9.487108] smartpqi 0000:23:00.0: failed to allocate PQI error buffer
      ....
      [  139.050544] dracut-initqueue[949]: Warning: dracut-initqueue timeout - starting timeout scripts
      [  139.589779] dracut-initqueue[949]: Warning: dracut-initqueue timeout - starting timeout scripts
      
      Basically, the fact that the coherent DMA mask value wasn't set caused the
      driver to fall back to SWIOTLB when SME is active.
      
      For correct operation, lets call the dma_set_mask_and_coherent() to
      properly set the mask for both streaming and coherent, in order to inform
      the kernel about the devices DMA addressing capabilities.
      Signed-off-by: default avatarLianbo Jiang <lijiang@redhat.com>
      Acked-by: default avatarDon Brace <don.brace@microsemi.com>
      Tested-by: default avatarDon Brace <don.brace@microsemi.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      1d94f06e
    • Steffen Maier's avatar
      scsi: zfcp: fix to prevent port_remove with pure auto scan LUNs (only sdevs) · ef4021fe
      Steffen Maier authored
      When the user tries to remove a zfcp port via sysfs, we only rejected it if
      there are zfcp unit children under the port. With purely automatically
      scanned LUNs there are no zfcp units but only SCSI devices. In such cases,
      the port_remove erroneously continued. We close the port and this
      implicitly closes all LUNs under the port. The SCSI devices survive with
      their private zfcp_scsi_dev still holding a reference to the "removed"
      zfcp_port (still allocated but invisible in sysfs) [zfcp_get_port_by_wwpn
      in zfcp_scsi_slave_alloc]. This is not a problem as long as the fc_rport
      stays blocked. Once (auto) port scan brings back the removed port, we
      unblock its fc_rport again by design.  However, there is no mechanism that
      would recover (open) the LUNs under the port (no "ersfs_3" without
      zfcp_unit [zfcp_erp_strategy_followup_success]).  Any pending or new I/O to
      such LUN leads to repeated:
      
        Done: NEEDS_RETRY Result: hostbyte=DID_IMM_RETRY driverbyte=DRIVER_OK
      
      See also v4.10 commit 6f2ce1c6 ("scsi: zfcp: fix rport unblock race
      with LUN recovery"). Even a manual LUN recovery
      (echo 0 > /sys/bus/scsi/devices/H:C:T:L/zfcp_failed)
      does not help, as the LUN links to the old "removed" port which remains
      to lack ZFCP_STATUS_COMMON_RUNNING [zfcp_erp_required_act].
      The only workaround is to first ensure that the fc_rport is blocked
      (e.g. port_remove again in case it was re-discovered by (auto) port scan),
      then delete the SCSI devices, and finally re-discover by (auto) port scan.
      The port scan includes an fc_rport unblock, which in turn triggers
      a new scan on the scsi target to freshly get new pure auto scan LUNs.
      
      Fix this by rejecting port_remove also if there are SCSI devices
      (even without any zfcp_unit) under this port. Re-use mechanics from v3.7
      commit d99b601b ("[SCSI] zfcp: restore refcount check on port_remove").
      However, we have to give up zfcp_sysfs_port_units_mutex earlier in unit_add
      to prevent a deadlock with scsi_host scan taking shost->scan_mutex first
      and then zfcp_sysfs_port_units_mutex now in our zfcp_scsi_slave_alloc().
      Signed-off-by: default avatarSteffen Maier <maier@linux.ibm.com>
      Fixes: b62a8d9b ("[SCSI] zfcp: Use SCSI device data zfcp scsi dev instead of zfcp unit")
      Fixes: f8210e34 ("[SCSI] zfcp: Allow midlayer to scan for LUNs when running in NPIV mode")
      Cc: <stable@vger.kernel.org> #2.6.37+
      Reviewed-by: default avatarBenjamin Block <bblock@linux.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      ef4021fe
    • Steffen Maier's avatar
      scsi: zfcp: fix missing zfcp_port reference put on -EBUSY from port_remove · d27e5e07
      Steffen Maier authored
      With this early return due to zfcp_unit child(ren), we don't use the
      zfcp_port reference from the earlier zfcp_get_port_by_wwpn() anymore and
      need to put it.
      Signed-off-by: default avatarSteffen Maier <maier@linux.ibm.com>
      Fixes: d99b601b ("[SCSI] zfcp: restore refcount check on port_remove")
      Cc: <stable@vger.kernel.org> #3.7+
      Reviewed-by: default avatarJens Remus <jremus@linux.ibm.com>
      Reviewed-by: default avatarBenjamin Block <bblock@linux.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      d27e5e07
    • Varun Prakash's avatar
      scsi: libcxgbi: add a check for NULL pointer in cxgbi_check_route() · cc555759
      Varun Prakash authored
      ip_dev_find() can return NULL so add a check for NULL pointer.
      Signed-off-by: default avatarVarun Prakash <varun@chelsio.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      cc555759
  5. 20 May, 2019 4 commits
  6. 14 May, 2019 7 commits
  7. 29 Apr, 2019 15 commits
    • Bart Van Assche's avatar
      scsi: qla2xxx: Avoid that lockdep complains about unsafe locking in tcm_qla2xxx_close_session() · d4023db7
      Bart Van Assche authored
      This patch avoids that lockdep reports the following warning:
      
      =====================================================
      WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
      5.1.0-rc1-dbg+ #11 Tainted: G        W
      -----------------------------------------------------
      rmdir/1478 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
      00000000e7ac4607 (&(&k->k_lock)->rlock){+.+.}, at: klist_next+0x43/0x1d0
      
      and this task is already holding:
      00000000cf0baf5e (&(&ha->tgt.sess_lock)->rlock){-...}, at: tcm_qla2xxx_close_session+0x57/0xb0 [tcm_qla2xxx]
      which would create a new lock dependency:
       (&(&ha->tgt.sess_lock)->rlock){-...} -> (&(&k->k_lock)->rlock){+.+.}
      
      but this new dependency connects a HARDIRQ-irq-safe lock:
       (&(&ha->tgt.sess_lock)->rlock){-...}
      
      ... which became HARDIRQ-irq-safe at:
        lock_acquire+0xe3/0x200
        _raw_spin_lock_irqsave+0x3d/0x60
        qla2x00_fcport_event_handler+0x1f3d/0x22b0 [qla2xxx]
        qla2x00_async_login_sp_done+0x1dc/0x1f0 [qla2xxx]
        qla24xx_process_response_queue+0xa37/0x10e0 [qla2xxx]
        qla24xx_msix_rsp_q+0x79/0xf0 [qla2xxx]
        __handle_irq_event_percpu+0x79/0x3c0
        handle_irq_event_percpu+0x70/0xf0
        handle_irq_event+0x5a/0x8b
        handle_edge_irq+0x12c/0x310
        handle_irq+0x192/0x20a
        do_IRQ+0x73/0x160
        ret_from_intr+0x0/0x1d
        default_idle+0x23/0x1f0
        arch_cpu_idle+0x15/0x20
        default_idle_call+0x35/0x40
        do_idle+0x2bb/0x2e0
        cpu_startup_entry+0x1d/0x20
        start_secondary+0x24d/0x2d0
        secondary_startup_64+0xa4/0xb0
      
      to a HARDIRQ-irq-unsafe lock:
       (&(&k->k_lock)->rlock){+.+.}
      
      ... which became HARDIRQ-irq-unsafe at:
      ...
        lock_acquire+0xe3/0x200
        _raw_spin_lock+0x32/0x50
        klist_add_tail+0x33/0xb0
        device_add+0x7f4/0xb60
        device_create_groups_vargs+0x11c/0x150
        device_create_with_groups+0x89/0xb0
        vtconsole_class_init+0xb2/0x124
        do_one_initcall+0xc5/0x3ce
        kernel_init_freeable+0x295/0x32e
        kernel_init+0x11/0x11b
        ret_from_fork+0x3a/0x50
      
      other info that might help us debug this:
      
       Possible interrupt unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&(&k->k_lock)->rlock);
                                     local_irq_disable();
                                     lock(&(&ha->tgt.sess_lock)->rlock);
                                     lock(&(&k->k_lock)->rlock);
        <Interrupt>
          lock(&(&ha->tgt.sess_lock)->rlock);
      
       *** DEADLOCK ***
      
      4 locks held by rmdir/1478:
       #0: 000000002c7f1ba4 (sb_writers#10){.+.+}, at: mnt_want_write+0x32/0x70
       #1: 00000000c85eb147 (&default_group_class[depth - 1]#2/1){+.+.}, at: do_rmdir+0x217/0x2d0
       #2: 000000002b164d6f (&sb->s_type->i_mutex_key#13){++++}, at: vfs_rmdir+0x7e/0x1d0
       #3: 00000000cf0baf5e (&(&ha->tgt.sess_lock)->rlock){-...}, at: tcm_qla2xxx_close_session+0x57/0xb0 [tcm_qla2xxx]
      
      the dependencies between HARDIRQ-irq-safe lock and the holding lock:
      -> (&(&ha->tgt.sess_lock)->rlock){-...} ops: 127 {
         IN-HARDIRQ-W at:
                          lock_acquire+0xe3/0x200
                          _raw_spin_lock_irqsave+0x3d/0x60
                          qla2x00_fcport_event_handler+0x1f3d/0x22b0 [qla2xxx]
                          qla2x00_async_login_sp_done+0x1dc/0x1f0 [qla2xxx]
                          qla24xx_process_response_queue+0xa37/0x10e0 [qla2xxx]
                          qla24xx_msix_rsp_q+0x79/0xf0 [qla2xxx]
                          __handle_irq_event_percpu+0x79/0x3c0
                          handle_irq_event_percpu+0x70/0xf0
                          handle_irq_event+0x5a/0x8b
                          handle_edge_irq+0x12c/0x310
                          handle_irq+0x192/0x20a
                          do_IRQ+0x73/0x160
                          ret_from_intr+0x0/0x1d
                          default_idle+0x23/0x1f0
                          arch_cpu_idle+0x15/0x20
                          default_idle_call+0x35/0x40
                          do_idle+0x2bb/0x2e0
                          cpu_startup_entry+0x1d/0x20
                          start_secondary+0x24d/0x2d0
                          secondary_startup_64+0xa4/0xb0
         INITIAL USE at:
                         lock_acquire+0xe3/0x200
                         _raw_spin_lock_irqsave+0x3d/0x60
                         qla2x00_loop_resync+0xb3d/0x2690 [qla2xxx]
                         qla2x00_do_dpc+0xcee/0xf30 [qla2xxx]
                         kthread+0x1d2/0x1f0
                         ret_from_fork+0x3a/0x50
       }
       ... key      at: [<ffffffffa125f700>] __key.62804+0x0/0xfffffffffff7e900 [qla2xxx]
       ... acquired at:
         __lock_acquire+0x11ed/0x1b60
         lock_acquire+0xe3/0x200
         _raw_spin_lock_irqsave+0x3d/0x60
         klist_next+0x43/0x1d0
         device_for_each_child+0x96/0x110
         scsi_target_block+0x3c/0x40 [scsi_mod]
         fc_remote_port_delete+0xe7/0x1c0 [scsi_transport_fc]
         qla2x00_mark_device_lost+0x4d3/0x500 [qla2xxx]
         qlt_unreg_sess+0x104/0x2c0 [qla2xxx]
         tcm_qla2xxx_close_session+0xa2/0xb0 [tcm_qla2xxx]
         target_shutdown_sessions+0x17b/0x190 [target_core_mod]
         core_tpg_del_initiator_node_acl+0xf3/0x1f0 [target_core_mod]
         target_fabric_nacl_base_release+0x25/0x30 [target_core_mod]
         config_item_release+0x9f/0x120 [configfs]
         config_item_put+0x29/0x2b [configfs]
         configfs_rmdir+0x3d2/0x520 [configfs]
         vfs_rmdir+0xb3/0x1d0
         do_rmdir+0x25c/0x2d0
         __x64_sys_rmdir+0x24/0x30
         do_syscall_64+0x77/0x220
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      the dependencies between the lock to be acquired
       and HARDIRQ-irq-unsafe lock:
      -> (&(&k->k_lock)->rlock){+.+.} ops: 14568 {
         HARDIRQ-ON-W at:
                          lock_acquire+0xe3/0x200
                          _raw_spin_lock+0x32/0x50
                          klist_add_tail+0x33/0xb0
                          device_add+0x7f4/0xb60
                          device_create_groups_vargs+0x11c/0x150
                          device_create_with_groups+0x89/0xb0
                          vtconsole_class_init+0xb2/0x124
                          do_one_initcall+0xc5/0x3ce
                          kernel_init_freeable+0x295/0x32e
                          kernel_init+0x11/0x11b
                          ret_from_fork+0x3a/0x50
         SOFTIRQ-ON-W at:
                          lock_acquire+0xe3/0x200
                          _raw_spin_lock+0x32/0x50
                          klist_add_tail+0x33/0xb0
                          device_add+0x7f4/0xb60
                          device_create_groups_vargs+0x11c/0x150
                          device_create_with_groups+0x89/0xb0
                          vtconsole_class_init+0xb2/0x124
                          do_one_initcall+0xc5/0x3ce
                          kernel_init_freeable+0x295/0x32e
                          kernel_init+0x11/0x11b
                          ret_from_fork+0x3a/0x50
         INITIAL USE at:
                         lock_acquire+0xe3/0x200
                         _raw_spin_lock+0x32/0x50
                         klist_add_tail+0x33/0xb0
                         device_add+0x7f4/0xb60
                         device_create_groups_vargs+0x11c/0x150
                         device_create_with_groups+0x89/0xb0
                         vtconsole_class_init+0xb2/0x124
                         do_one_initcall+0xc5/0x3ce
                         kernel_init_freeable+0x295/0x32e
                         kernel_init+0x11/0x11b
                         ret_from_fork+0x3a/0x50
       }
       ... key      at: [<ffffffff83f3d900>] __key.15805+0x0/0x40
       ... acquired at:
         __lock_acquire+0x11ed/0x1b60
         lock_acquire+0xe3/0x200
         _raw_spin_lock_irqsave+0x3d/0x60
         klist_next+0x43/0x1d0
         device_for_each_child+0x96/0x110
         scsi_target_block+0x3c/0x40 [scsi_mod]
         fc_remote_port_delete+0xe7/0x1c0 [scsi_transport_fc]
         qla2x00_mark_device_lost+0x4d3/0x500 [qla2xxx]
         qlt_unreg_sess+0x104/0x2c0 [qla2xxx]
         tcm_qla2xxx_close_session+0xa2/0xb0 [tcm_qla2xxx]
         target_shutdown_sessions+0x17b/0x190 [target_core_mod]
         core_tpg_del_initiator_node_acl+0xf3/0x1f0 [target_core_mod]
         target_fabric_nacl_base_release+0x25/0x30 [target_core_mod]
         config_item_release+0x9f/0x120 [configfs]
         config_item_put+0x29/0x2b [configfs]
         configfs_rmdir+0x3d2/0x520 [configfs]
         vfs_rmdir+0xb3/0x1d0
         do_rmdir+0x25c/0x2d0
         __x64_sys_rmdir+0x24/0x30
         do_syscall_64+0x77/0x220
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      stack backtrace:
      CPU: 7 PID: 1478 Comm: rmdir Tainted: G        W         5.1.0-rc1-dbg+ #11
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      Call Trace:
       dump_stack+0x86/0xca
       check_usage.cold.59+0x473/0x563
       check_prev_add.constprop.43+0x1f1/0x1170
       __lock_acquire+0x11ed/0x1b60
       lock_acquire+0xe3/0x200
       _raw_spin_lock_irqsave+0x3d/0x60
       klist_next+0x43/0x1d0
       device_for_each_child+0x96/0x110
       scsi_target_block+0x3c/0x40 [scsi_mod]
       fc_remote_port_delete+0xe7/0x1c0 [scsi_transport_fc]
       qla2x00_mark_device_lost+0x4d3/0x500 [qla2xxx]
       qlt_unreg_sess+0x104/0x2c0 [qla2xxx]
       tcm_qla2xxx_close_session+0xa2/0xb0 [tcm_qla2xxx]
       target_shutdown_sessions+0x17b/0x190 [target_core_mod]
       core_tpg_del_initiator_node_acl+0xf3/0x1f0 [target_core_mod]
       target_fabric_nacl_base_release+0x25/0x30 [target_core_mod]
       config_item_release+0x9f/0x120 [configfs]
       config_item_put+0x29/0x2b [configfs]
       configfs_rmdir+0x3d2/0x520 [configfs]
       vfs_rmdir+0xb3/0x1d0
       do_rmdir+0x25c/0x2d0
       __x64_sys_rmdir+0x24/0x30
       do_syscall_64+0x77/0x220
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Cc: Himanshu Madhani <hmadhani@marvell.com>
      Cc: Giridhar Malavali <gmalavali@marvell.com>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Acked-by: default avatarHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      d4023db7
    • Bart Van Assche's avatar
      scsi: qla2xxx: Avoid that qlt_send_resp_ctio() corrupts memory · a861b492
      Bart Van Assche authored
      The "(&ctio->u.status1.sense_data)[i]" where i >= 0 expressions in
      qlt_send_resp_ctio() are probably typos and should have been
      "(&ctio->u.status1.sense_data[4 * i])" instead. Instead of only fixing
      these typos, modify the code for storing sense data such that it becomes
      easy to read. This patch fixes a Coverity complaint about accessing an
      array outside its bounds.
      
      Cc: Himanshu Madhani <hmadhani@marvell.com>
      Cc: Giridhar Malavali <gmalavali@marvell.com>
      Fixes: be25152c ("qla2xxx: Improve T10-DIF/PI handling in driver.") # v4.11.
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Acked-by: default avatarHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      a861b492
    • Bart Van Assche's avatar
      scsi: qla2xxx: Fix hardirq-unsafe locking · 300ec741
      Bart Van Assche authored
      Since fc_remote_port_delete() must be called with interrupts enabled, do
      not disable interrupts when calling that function. Remove the lockin calls
      from around the put_sess() call. This is safe because the function that is
      called when the final reference is dropped, qlt_unreg_sess(), grabs the
      proper locks. This patch avoids that lockdep reports the following:
      
      WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
      kworker/2:1/62 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
      0000000009e679b3 (&(&k->k_lock)->rlock){+.+.}, at: klist_next+0x43/0x1d0
      
      and this task is already holding:
      00000000a033b71c (&(&ha->tgt.sess_lock)->rlock){-...}, at: qla24xx_delete_sess_fn+0x55/0xf0 [qla2xxx_scst]
      which would create a new lock dependency:
       (&(&ha->tgt.sess_lock)->rlock){-...} -> (&(&k->k_lock)->rlock){+.+.}
      
      but this new dependency connects a HARDIRQ-irq-safe lock:
       (&(&ha->tgt.sess_lock)->rlock){-...}
      
      ... which became HARDIRQ-irq-safe at:
        lock_acquire+0xe3/0x200
        _raw_spin_lock_irqsave+0x3d/0x60
        qla24xx_report_id_acquisition+0xa69/0xe30 [qla2xxx_scst]
        qla24xx_process_response_queue+0x69e/0x1270 [qla2xxx_scst]
        qla24xx_msix_rsp_q+0x79/0xf0 [qla2xxx_scst]
        __handle_irq_event_percpu+0x79/0x3c0
        handle_irq_event_percpu+0x70/0xf0
        handle_irq_event+0x5a/0x8b
        handle_edge_irq+0x12c/0x310
        handle_irq+0x192/0x20a
        do_IRQ+0x73/0x160
        ret_from_intr+0x0/0x1d
        default_idle+0x23/0x1f0
        arch_cpu_idle+0x15/0x20
        default_idle_call+0x35/0x40
        do_idle+0x2bb/0x2e0
        cpu_startup_entry+0x1d/0x20
        start_secondary+0x2a8/0x320
        secondary_startup_64+0xa4/0xb0
      
      to a HARDIRQ-irq-unsafe lock:
       (&(&k->k_lock)->rlock){+.+.}
      
      ... which became HARDIRQ-irq-unsafe at:
      ...
        lock_acquire+0xe3/0x200
        _raw_spin_lock+0x32/0x50
        klist_add_tail+0x33/0xb0
        device_add+0x7e1/0xb50
        device_create_groups_vargs+0x11c/0x150
        device_create_with_groups+0x89/0xb0
        vtconsole_class_init+0xb2/0x124
        do_one_initcall+0xc5/0x3ce
        kernel_init_freeable+0x295/0x32e
        kernel_init+0x11/0x11b
        ret_from_fork+0x3a/0x50
      
      other info that might help us debug this:
      
       Possible interrupt unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&(&k->k_lock)->rlock);
                                     local_irq_disable();
                                     lock(&(&ha->tgt.sess_lock)->rlock);
                                     lock(&(&k->k_lock)->rlock);
        <Interrupt>
          lock(&(&ha->tgt.sess_lock)->rlock);
      
       *** DEADLOCK ***
      
      3 locks held by kworker/2:1/62:
       #0: 00000000a4319c16 ((wq_completion)"qla2xxx_wq"){+.+.}, at: process_one_work+0x437/0xa80
       #1: 00000000ffa34c42 ((work_completion)(&sess->del_work)){+.+.}, at: process_one_work+0x437/0xa80
       #2: 00000000a033b71c (&(&ha->tgt.sess_lock)->rlock){-...}, at: qla24xx_delete_sess_fn+0x55/0xf0 [qla2xxx_scst]
      
      the dependencies between HARDIRQ-irq-safe lock and the holding lock:
      -> (&(&ha->tgt.sess_lock)->rlock){-...} ops: 8 {
         IN-HARDIRQ-W at:
                          lock_acquire+0xe3/0x200
                          _raw_spin_lock_irqsave+0x3d/0x60
                          qla24xx_report_id_acquisition+0xa69/0xe30 [qla2xxx_scst]
                          qla24xx_process_response_queue+0x69e/0x1270 [qla2xxx_scst]
                          qla24xx_msix_rsp_q+0x79/0xf0 [qla2xxx_scst]
                          __handle_irq_event_percpu+0x79/0x3c0
                          handle_irq_event_percpu+0x70/0xf0
                          handle_irq_event+0x5a/0x8b
                          handle_edge_irq+0x12c/0x310
                          handle_irq+0x192/0x20a
                          do_IRQ+0x73/0x160
                          ret_from_intr+0x0/0x1d
                          default_idle+0x23/0x1f0
                          arch_cpu_idle+0x15/0x20
                          default_idle_call+0x35/0x40
                          do_idle+0x2bb/0x2e0
                          cpu_startup_entry+0x1d/0x20
                          start_secondary+0x2a8/0x320
                          secondary_startup_64+0xa4/0xb0
         INITIAL USE at:
                         lock_acquire+0xe3/0x200
                         _raw_spin_lock_irqsave+0x3d/0x60
                         qla24xx_report_id_acquisition+0xa69/0xe30 [qla2xxx_scst]
                         qla24xx_process_response_queue+0x69e/0x1270 [qla2xxx_scst]
                         qla24xx_msix_rsp_q+0x79/0xf0 [qla2xxx_scst]
                         __handle_irq_event_percpu+0x79/0x3c0
                         handle_irq_event_percpu+0x70/0xf0
                         handle_irq_event+0x5a/0x8b
                         handle_edge_irq+0x12c/0x310
                         handle_irq+0x192/0x20a
                         do_IRQ+0x73/0x160
                         ret_from_intr+0x0/0x1d
                         default_idle+0x23/0x1f0
                         arch_cpu_idle+0x15/0x20
                         default_idle_call+0x35/0x40
                         do_idle+0x2bb/0x2e0
                         cpu_startup_entry+0x1d/0x20
                         start_secondary+0x2a8/0x320
                         secondary_startup_64+0xa4/0xb0
       }
       ... key      at: [<ffffffffa0c0d080>] __key.85462+0x0/0xfffffffffff7df80 [qla2xxx_scst]
       ... acquired at:
         lock_acquire+0xe3/0x200
         _raw_spin_lock_irqsave+0x3d/0x60
         klist_next+0x43/0x1d0
         device_for_each_child+0x96/0x110
         scsi_target_block+0x3c/0x40 [scsi_mod]
         fc_remote_port_delete+0xe7/0x1c0 [scsi_transport_fc]
         qla2x00_mark_device_lost+0xa0b/0xa30 [qla2xxx_scst]
         qlt_unreg_sess+0x1c6/0x380 [qla2xxx_scst]
         qla24xx_delete_sess_fn+0xe6/0xf0 [qla2xxx_scst]
         process_one_work+0x511/0xa80
         worker_thread+0x67/0x5b0
         kthread+0x1d2/0x1f0
         ret_from_fork+0x3a/0x50
      
      the dependencies between the lock to be acquired
       and HARDIRQ-irq-unsafe lock:
      -> (&(&k->k_lock)->rlock){+.+.} ops: 13831 {
         HARDIRQ-ON-W at:
                          lock_acquire+0xe3/0x200
                          _raw_spin_lock+0x32/0x50
                          klist_add_tail+0x33/0xb0
                          device_add+0x7e1/0xb50
                          device_create_groups_vargs+0x11c/0x150
                          device_create_with_groups+0x89/0xb0
                          vtconsole_class_init+0xb2/0x124
                          do_one_initcall+0xc5/0x3ce
                          kernel_init_freeable+0x295/0x32e
                          kernel_init+0x11/0x11b
                          ret_from_fork+0x3a/0x50
         SOFTIRQ-ON-W at:
                          lock_acquire+0xe3/0x200
                          _raw_spin_lock+0x32/0x50
                          klist_add_tail+0x33/0xb0
                          device_add+0x7e1/0xb50
                          device_create_groups_vargs+0x11c/0x150
                          device_create_with_groups+0x89/0xb0
                          vtconsole_class_init+0xb2/0x124
                          do_one_initcall+0xc5/0x3ce
                          kernel_init_freeable+0x295/0x32e
                          kernel_init+0x11/0x11b
                          ret_from_fork+0x3a/0x50
         INITIAL USE at:
                         lock_acquire+0xe3/0x200
                         _raw_spin_lock+0x32/0x50
                         klist_add_tail+0x33/0xb0
                         device_add+0x7e1/0xb50
                         device_create_groups_vargs+0x11c/0x150
                         device_create_with_groups+0x89/0xb0
                         vtconsole_class_init+0xb2/0x124
                         do_one_initcall+0xc5/0x3ce
                         kernel_init_freeable+0x295/0x32e
                         kernel_init+0x11/0x11b
                         ret_from_fork+0x3a/0x50
       }
       ... key      at: [<ffffffff83ed8780>] __key.15491+0x0/0x40
       ... acquired at:
         lock_acquire+0xe3/0x200
         _raw_spin_lock_irqsave+0x3d/0x60
         klist_next+0x43/0x1d0
         device_for_each_child+0x96/0x110
         scsi_target_block+0x3c/0x40 [scsi_mod]
         fc_remote_port_delete+0xe7/0x1c0 [scsi_transport_fc]
         qla2x00_mark_device_lost+0xa0b/0xa30 [qla2xxx_scst]
         qlt_unreg_sess+0x1c6/0x380 [qla2xxx_scst]
         qla24xx_delete_sess_fn+0xe6/0xf0 [qla2xxx_scst]
         process_one_work+0x511/0xa80
         worker_thread+0x67/0x5b0
         kthread+0x1d2/0x1f0
         ret_from_fork+0x3a/0x50
      
      stack backtrace:
      CPU: 2 PID: 62 Comm: kworker/2:1 Tainted: G           O      5.0.7-dbg+ #8
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      Workqueue: qla2xxx_wq qla24xx_delete_sess_fn [qla2xxx_scst]
      Call Trace:
       dump_stack+0x86/0xca
       check_usage.cold.52+0x473/0x563
       __lock_acquire+0x11c0/0x23e0
       lock_acquire+0xe3/0x200
       _raw_spin_lock_irqsave+0x3d/0x60
       klist_next+0x43/0x1d0
       device_for_each_child+0x96/0x110
       scsi_target_block+0x3c/0x40 [scsi_mod]
       fc_remote_port_delete+0xe7/0x1c0 [scsi_transport_fc]
       qla2x00_mark_device_lost+0xa0b/0xa30 [qla2xxx_scst]
       qlt_unreg_sess+0x1c6/0x380 [qla2xxx_scst]
       qla24xx_delete_sess_fn+0xe6/0xf0 [qla2xxx_scst]
       process_one_work+0x511/0xa80
       worker_thread+0x67/0x5b0
       kthread+0x1d2/0x1f0
       ret_from_fork+0x3a/0x50
      
      Cc: Himanshu Madhani <hmadhani@marvell.com>
      Cc: Giridhar Malavali <gmalavali@marvell.com>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Acked-by: default avatarHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      300ec741
    • Bart Van Assche's avatar
      scsi: qla2xxx: Complain loudly about reference count underflow · db4bf822
      Bart Van Assche authored
      A reference count underflow is a severe bug. Hence complain loudly if a
      reference count underflow happens.
      
      Cc: Himanshu Madhani <hmadhani@marvell.com>
      Cc: Giridhar Malavali <gmalavali@marvell.com>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Acked-by: default avatarHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      db4bf822
    • Bart Van Assche's avatar
      scsi: qla2xxx: Use __le64 instead of uint32_t[2] for sending DMA addresses to firmware · d4556a49
      Bart Van Assche authored
      This patch makes the code easier to read and more compact.
      
      Cc: Himanshu Madhani <hmadhani@marvell.com>
      Cc: Giridhar Malavali <gmalavali@marvell.com>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Acked-by: default avatarHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      d4556a49
    • Bart Van Assche's avatar
      scsi: qla2xxx: Introduce the dsd32 and dsd64 data structures · 15b7a68c
      Bart Van Assche authored
      Introduce two structures for the (DMA address, length) combination instead
      of using separate structure members for the DMA address and length. This
      patch fixes several Coverity complaints about 'cur_dsd' being used to write
      outside the bounds of structure members.
      
      Cc: Himanshu Madhani <hmadhani@marvell.com>
      Cc: Giridhar Malavali <gmalavali@marvell.com>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Acked-by: default avatarHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      15b7a68c
    • Bart Van Assche's avatar
      scsi: qla2xxx: Check the size of firmware data structures at compile time · bc04459c
      Bart Van Assche authored
      Since the next patch will modify several firmware data structures, add
      compile time checks that verify that these structures have the correct
      size.
      
      Cc: Himanshu Madhani <hmadhani@marvell.com>
      Cc: Giridhar Malavali <gmalavali@marvell.com>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Acked-by: default avatarHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      bc04459c
    • Bart Van Assche's avatar
      scsi: qla2xxx: Pass little-endian values to the firmware · 6e73985a
      Bart Van Assche authored
      Pass dsd_list_len in little endian format to the firmware instead of in CPU
      endian format.
      
      Cc: Himanshu Madhani <hmadhani@marvell.com>
      Cc: Giridhar Malavali <gmalavali@marvell.com>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Acked-by: default avatarHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      6e73985a
    • Bart Van Assche's avatar
      scsi: qla2xxx: Fix race conditions in the code for aborting SCSI commands · 219d27d7
      Bart Van Assche authored
      In the *_done() functions, instead of returning early if sp->ref_count >=
      2, only decrement sp->ref_count. In qla2xxx_eh_abort(), instead of deciding
      what to do based on the value of sp->ref_count, decide which action to take
      depending on the completion status of the firmware abort. Remove srb.cwaitq
      and use srb.comp instead. In qla2x00_abort_srb(), call
      isp_ops->abort_command() directly instead of calling qla2xxx_eh_abort().
      
      Cc: Himanshu Madhani <hmadhani@marvell.com>
      Cc: Giridhar Malavali <gmalavali@marvell.com>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Acked-by: default avatarHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      219d27d7
    • Bart Van Assche's avatar
      scsi: qla2xxx: Use an on-stack completion in qla24xx_control_vp() · 982cc4be
      Bart Van Assche authored
      This patch reduces the size of struct srb.
      
      Cc: Himanshu Madhani <hmadhani@marvell.com>
      Cc: Giridhar Malavali <gmalavali@marvell.com>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Acked-by: default avatarHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      982cc4be
    • Bart Van Assche's avatar
      scsi: qla2xxx: Make qla24xx_async_abort_cmd() static · 1956eee5
      Bart Van Assche authored
      Since qla24xx_async_abort_cmd() is only called from inside qla_init.c,
      declare that function static. Reorder a few functions to avoid that any
      forward declarations are needed.
      
      Cc: Himanshu Madhani <hmadhani@marvell.com>
      Cc: Giridhar Malavali <gmalavali@marvell.com>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Acked-by: default avatarHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      1956eee5
    • Bart Van Assche's avatar
      scsi: qla2xxx: Remove unnecessary locking from the target code · 1b1e68d2
      Bart Van Assche authored
      All callbacks from the target core into the qla2xxx driver and also all I/O
      completion functions are serialized per command. Since .cmd_sent_to_fw and
      .trc_flags are only modified from inside these functions it is not
      necessary to protect it with locking. Remove the superfluous locking.
      
      Cc: Himanshu Madhani <hmadhani@marvell.com>
      Cc: Giridhar Malavali <gmalavali@marvell.com>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Acked-by: default avatarHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      1b1e68d2
    • Bart Van Assche's avatar
      scsi: qla2xxx: Remove qla_tgt_cmd.released · 4c374596
      Bart Van Assche authored
      Since the previous patch removed the only statement that sets
      qla_tgt_cmd.released, remove the code that depends on that member variable
      being set and the member variable itself.
      
      Cc: Himanshu Madhani <hmadhani@marvell.com>
      Cc: Giridhar Malavali <gmalavali@marvell.com>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Acked-by: default avatarHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      4c374596
    • Bart Van Assche's avatar
      scsi: qla2xxx: Complain if a command is released that is owned by the firmware · b1e261d4
      Bart Van Assche authored
      The previous patch guarantees that a command is only released after the
      firmware has finished processing it. Hence complain if a command is
      released that is owned by the firmware.
      
      Cc: Himanshu Madhani <hmadhani@marvell.com>
      Cc: Giridhar Malavali <gmalavali@marvell.com>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Acked-by: default avatarHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      b1e261d4
    • Bart Van Assche's avatar
      scsi: qla2xxx: target: Fix offline port handling and host reset handling · aefed3e5
      Bart Van Assche authored
      Remove the function qlt_abort_cmd_on_host_reset() because it can do the
      following, all of which can cause a kernel crash:
      
      - DMA unmapping while DMA is in progress.
      - Call target_execute_cmd() while DMA is in progress.
      - Call transport_generic_free_cmd() while the LIO core owns a command.
      
      Instead of trying to abort a command asynchronously, set the 'aborted' flag
      and handle the abort after the hardware has passed control back to the
      tcm_qla2xxx driver.
      
      Cc: Arun Easi <arun.easi@qlogic.com>
      Cc: Himanshu Madhani <hmadhani@marvell.com>
      Cc: Giridhar Malavali <gmalavali@marvell.com>
      Fixes: c0cb4496 ("qla2xxx: Add Host reset handling in target mode.") # v3.18.
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Acked-by: default avatarHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      aefed3e5