From fbce4d97fd4333bcffd00a73b9d98412be630332 Mon Sep 17 00:00:00 2001 From: Hannes Reinecke Date: Wed, 4 Oct 2017 10:28:56 +0200 Subject: scsi: fixup kernel warning during rmmod() Calling rmmod() on a FC driver will results in warnings like WARNING: CPU: 60 PID: 14640 at fs/sysfs/group.c:237 device_del+0x54/0x240() sysfs group ffffffff81eff140 not found for kobject '3:0:0:3' The problem here is that during scsi_remove_target() we will iterate over all devices, but fail to remove any of those as the call to scsi_device_get() fails the check to module_is_live(). Hence the devices will not be removed at this point, but all intermediate structures like fc rport etc. will be. Later on during scsi_forget_host() the devices are removed for real, but the device parent is already removed and causes this warning. Signed-off-by: Hannes Reinecke Reviewed-by: Johannes Thumshirn Reviewed-by: Kyle Fortin Tested-by: Don Brace Signed-off-by: Martin K. Petersen --- drivers/scsi/scsi_sysfs.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) (limited to 'drivers/scsi') diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c index bf53356..f796bd6 100644 --- a/drivers/scsi/scsi_sysfs.c +++ b/drivers/scsi/scsi_sysfs.c @@ -1376,13 +1376,19 @@ static void __scsi_remove_target(struct scsi_target *starget) spin_lock_irqsave(shost->host_lock, flags); restart: list_for_each_entry(sdev, &shost->__devices, siblings) { + /* + * We cannot call scsi_device_get() here, as + * we might've been called from rmmod() causing + * scsi_device_get() to fail the module_is_live() + * check. + */ if (sdev->channel != starget->channel || sdev->id != starget->id || - scsi_device_get(sdev)) + !get_device(&sdev->sdev_gendev)) continue; spin_unlock_irqrestore(shost->host_lock, flags); scsi_remove_device(sdev); - scsi_device_put(sdev); + put_device(&sdev->sdev_gendev); spin_lock_irqsave(shost->host_lock, flags); goto restart; } -- cgit v1.1 From d1b3f51ee1eab3a6db1b09a60e61280c48eb0b01 Mon Sep 17 00:00:00 2001 From: Satish Kharat Date: Thu, 5 Oct 2017 16:41:21 -0700 Subject: scsi: libfc: fix a deadlock in fc_rport_work In places like fc_rport_recv_plogi_req and fcoe_ctlr_vn_add we always take the lport disc_mutex lock before the rports mutex (rp_mutex) lock. Gaurding list_del_rcu(&rdata->peers) with disc.disc_mutex in fc_rport_work is correct but the rp_mutex lock can and should to be dropped before taking that lock else results in a deadlock. Signed-off-by: Satish Kharat Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen --- drivers/scsi/libfc/fc_rport.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/scsi') diff --git a/drivers/scsi/libfc/fc_rport.c b/drivers/scsi/libfc/fc_rport.c index 5203258..31d31aa 100644 --- a/drivers/scsi/libfc/fc_rport.c +++ b/drivers/scsi/libfc/fc_rport.c @@ -383,11 +383,11 @@ static void fc_rport_work(struct work_struct *work) fc_rport_enter_flogi(rdata); mutex_unlock(&rdata->rp_mutex); } else { + mutex_unlock(&rdata->rp_mutex); FC_RPORT_DBG(rdata, "work delete\n"); mutex_lock(&lport->disc.disc_mutex); list_del_rcu(&rdata->peers); mutex_unlock(&lport->disc.disc_mutex); - mutex_unlock(&rdata->rp_mutex); kref_put(&rdata->kref, fc_rport_destroy); } } else { -- cgit v1.1 From eef9ffdf9cd39b2986367bc8395e2772bc1284ba Mon Sep 17 00:00:00 2001 From: Johannes Thumshirn Date: Mon, 9 Oct 2017 13:33:19 +0200 Subject: scsi: libiscsi: fix shifting of DID_REQUEUE host byte The SCSI host byte should be shifted left by 16 in order to have scsi_decide_disposition() do the right thing (.i.e. requeue the command). Signed-off-by: Johannes Thumshirn Fixes: 661134ad3765 ("[SCSI] libiscsi, bnx2i: make bound ep check common") Cc: Lee Duncan Cc: Hannes Reinecke Cc: Bart Van Assche Cc: Chris Leech Acked-by: Lee Duncan Signed-off-by: Martin K. Petersen --- drivers/scsi/libiscsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/scsi') diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c index c62e8d11..f8dc160 100644 --- a/drivers/scsi/libiscsi.c +++ b/drivers/scsi/libiscsi.c @@ -1728,7 +1728,7 @@ int iscsi_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *sc) if (test_bit(ISCSI_SUSPEND_BIT, &conn->suspend_tx)) { reason = FAILURE_SESSION_IN_RECOVERY; - sc->result = DID_REQUEUE; + sc->result = DID_REQUEUE << 16; goto fault; } -- cgit v1.1 From a9e170e28636fd577249f39029d59e4e960a42b8 Mon Sep 17 00:00:00 2001 From: Quinn Tran Date: Tue, 10 Oct 2017 12:08:22 -0700 Subject: scsi: qla2xxx: Fix uninitialized work element Fixes following stack trace kernel: Call Trace: kernel: dump_stack+0x63/0x84 kernel: __warn+0xd1/0xf0 kernel: warn_slowpath_null+0x1d/0x20 kernel: __queue_work+0x37a/0x420 kernel: queue_work_on+0x27/0x40 kernel: queue_work+0x14/0x20 [qla2xxx] kernel: schedule_work+0x13/0x20 [qla2xxx] kernel: qla2x00_post_work+0xab/0xb0 [qla2xxx] kernel: qla2x00_post_aen_work+0x3b/0x50 [qla2xxx] kernel: qla2x00_async_event+0x20d/0x15d0 [qla2xxx] kernel: ? lock_timer_base+0x7d/0xa0 kernel: qla24xx_intr_handler+0x1da/0x310 [qla2xxx] kernel: qla2x00_poll+0x36/0x60 [qla2xxx] kernel: qla2x00_mailbox_command+0x659/0xec0 [qla2xxx] kernel: ? proc_create_data+0x7a/0xd0 kernel: qla25xx_init_rsp_que+0x15b/0x240 [qla2xxx] kernel: ? request_irq+0x14/0x20 [qla2xxx] kernel: qla25xx_create_rsp_que+0x256/0x3c0 [qla2xxx] kernel: qla2xxx_create_qpair+0x2af/0x5b0 [qla2xxx] kernel: qla2x00_probe_one+0x1107/0x1c30 [qla2xxx] Fixes: ec7193e26055 ("qla2xxx: Fix delayed response to command for loop mode/direct connect.") Cc: # 4.13 Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen --- drivers/scsi/qla2xxx/qla_os.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'drivers/scsi') diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c index 5b2437a..9372098 100644 --- a/drivers/scsi/qla2xxx/qla_os.c +++ b/drivers/scsi/qla2xxx/qla_os.c @@ -3175,6 +3175,8 @@ qla2x00_probe_one(struct pci_dev *pdev, const struct pci_device_id *id) host->can_queue, base_vha->req, base_vha->mgmt_svr_loop_id, host->sg_tablesize); + INIT_WORK(&base_vha->iocb_work, qla2x00_iocb_work_fn); + if (ha->mqenable) { bool mq = false; bool startit = false; @@ -3223,7 +3225,6 @@ qla2x00_probe_one(struct pci_dev *pdev, const struct pci_device_id *id) */ qla2xxx_wake_dpc(base_vha); - INIT_WORK(&base_vha->iocb_work, qla2x00_iocb_work_fn); INIT_WORK(&ha->board_disable, qla2x00_disable_board_on_pci_error); if (IS_QLA8031(ha) || IS_MCTP_CAPABLE(ha)) { -- cgit v1.1 From 8d30371fd7c328e192d7ea3108bd71b903631d6a Mon Sep 17 00:00:00 2001 From: Johannes Thumshirn Date: Tue, 10 Oct 2017 17:31:38 +0200 Subject: scsi: fc: check for rport presence in fc_block_scsi_eh Coverity-scan recently found a possible NULL pointer dereference in fc_block_scsi_eh() as starget_to_rport() either returns the rport for the startget or NULL. While it is rather unlikely to have fc_block_scsi_eh() called without an rport associated it's a good idea to catch potential misuses of the API gracefully. Signed-off-by: Johannes Thumshirn Reviewed-by: Bart Van Assche Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen --- drivers/scsi/scsi_transport_fc.c | 3 +++ 1 file changed, 3 insertions(+) (limited to 'drivers/scsi') diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c index cbd4495..8c46a6d 100644 --- a/drivers/scsi/scsi_transport_fc.c +++ b/drivers/scsi/scsi_transport_fc.c @@ -3320,6 +3320,9 @@ int fc_block_scsi_eh(struct scsi_cmnd *cmnd) { struct fc_rport *rport = starget_to_rport(scsi_target(cmnd->device)); + if (WARN_ON_ONCE(!rport)) + return FAST_IO_FAIL; + return fc_block_rport(rport); } EXPORT_SYMBOL(fc_block_scsi_eh); -- cgit v1.1