From fb9024b0646939e59d8a0b6799b317070619795a Mon Sep 17 00:00:00 2001 From: "Ewan D. Milne" Date: Mon, 4 May 2020 13:54:16 -0400 Subject: [PATCH 1/3] scsi: qla2xxx: Do not log message when reading port speed via sysfs Calling ql_log() inside qla2x00_port_speed_show() is causing messages to be output to the console for no particularly good reason. The sysfs read routine should just return the information to userspace. The only reason to log a message is when the port speed actually changes, and this already occurs elsewhere. Link: https://lore.kernel.org/r/20200504175416.15417-1-emilne@redhat.com Fixes: 4910b524ac9e ("scsi: qla2xxx: Add support for setting port speed") Cc: # v5.1+ Reviewed-by: Lee Duncan Reviewed-by: Laurence Oberman Reviewed-by: Himanshu Madhani Signed-off-by: Ewan D. Milne Signed-off-by: Martin K. Petersen --- drivers/scsi/qla2xxx/qla_attr.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/scsi/qla2xxx/qla_attr.c b/drivers/scsi/qla2xxx/qla_attr.c index 33255968f03a..2c9e5ac24692 100644 --- a/drivers/scsi/qla2xxx/qla_attr.c +++ b/drivers/scsi/qla2xxx/qla_attr.c @@ -1850,9 +1850,6 @@ qla2x00_port_speed_show(struct device *dev, struct device_attribute *attr, return -EINVAL; } - ql_log(ql_log_info, vha, 0x70d6, - "port speed:%d\n", ha->link_data_rate); - return scnprintf(buf, PAGE_SIZE, "%s\n", spd[ha->link_data_rate]); } From 05d18ae1cc8a0308b12f37b4ab94afce3535fac9 Mon Sep 17 00:00:00 2001 From: Can Guo Date: Tue, 5 May 2020 21:55:35 -0700 Subject: [PATCH 2/3] scsi: pm: Balance pm_only counter of request queue during system resume During system resume, scsi_resume_device() decreases a request queue's pm_only counter if the scsi device was quiesced before. But after that, if the scsi device's RPM status is RPM_SUSPENDED, the pm_only counter is still held (non-zero). Current SCSI resume hook only sets the RPM status of the scsi_device and its request queue to RPM_ACTIVE, but leaves the pm_only counter unchanged. This may make the request queue's pm_only counter remain non-zero after resume hook returns, hence those who are waiting on the mq_freeze_wq would never be woken up. Fix this by calling blk_post_runtime_resume() if a sdev's RPM status was RPM_SUSPENDED. (struct request_queue)0xFFFFFF815B69E938 pm_only = (counter = 2), rpm_status = 0, dev = 0xFFFFFF815B0511A0, ((struct device)0xFFFFFF815B0511A0)).power is_suspended = FALSE, runtime_status = RPM_ACTIVE, (struct scsi_device)0xffffff815b051000 request_queue = 0xFFFFFF815B69E938, sdev_state = SDEV_RUNNING, quiesced_by = 0x0, B::v.f_/task_0xFFFFFF810C246940 -000|__switch_to(prev = 0xFFFFFF810C246940, next = 0xFFFFFF80A49357C0) -001|context_switch(inline) -001|__schedule(?) -002|schedule() -003|blk_queue_enter(q = 0xFFFFFF815B69E938, flags = 0) -004|generic_make_request(?) -005|submit_bio(bio = 0xFFFFFF80A8195B80) Link: https://lore.kernel.org/r/1588740936-28846-1-git-send-email-cang@codeaurora.org Reviewed-by: Bart Van Assche Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen --- drivers/scsi/scsi_pm.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c index 3717eea37ecb..5f0ad8b32e3a 100644 --- a/drivers/scsi/scsi_pm.c +++ b/drivers/scsi/scsi_pm.c @@ -80,6 +80,10 @@ static int scsi_dev_type_resume(struct device *dev, dev_dbg(dev, "scsi resume: %d\n", err); if (err == 0) { + bool was_runtime_suspended; + + was_runtime_suspended = pm_runtime_suspended(dev); + pm_runtime_disable(dev); err = pm_runtime_set_active(dev); pm_runtime_enable(dev); @@ -93,8 +97,10 @@ static int scsi_dev_type_resume(struct device *dev, */ if (!err && scsi_is_sdev_device(dev)) { struct scsi_device *sdev = to_scsi_device(dev); - - blk_set_runtime_active(sdev->request_queue); + if (was_runtime_suspended) + blk_post_runtime_resume(sdev->request_queue, 0); + else + blk_set_runtime_active(sdev->request_queue); } } From f2e6b75f6ee82308ef7b00f29e71e5f1c6b3d52a Mon Sep 17 00:00:00 2001 From: Bodo Stroesser Date: Wed, 13 May 2020 17:34:43 +0200 Subject: [PATCH 3/3] scsi: target: Put lun_ref at end of tmr processing Testing with Loopback I found that, after a Loopback LUN has executed a TMR, I can no longer unlink the LUN. The rm command hangs in transport_clear_lun_ref() at wait_for_completion(&lun->lun_shutdown_comp) The reason is, that transport_lun_remove_cmd() is not called at the end of target_tmr_work(). It seems, that in other fabrics this call happens implicitly when the fabric drivers call transport_generic_free_cmd() during their ->queue_tm_rsp(). Unfortunately Loopback seems to not comply to the common way of calling transport_generic_free_cmd() from ->queue_*(). Instead it calls transport_generic_free_cmd() from its ->check_stop_free() only. But the ->check_stop_free() is called by transport_cmd_check_stop_to_fabric() after it has reset the se_cmd->se_lun pointer. Therefore the following transport_generic_free_cmd() skips the transport_lun_remove_cmd(). So this patch re-adds the transport_lun_remove_cmd() at the end of target_tmr_work(), which was removed during commit 2c9fa49e100f ("scsi: target/core: Make ABORT and LUN RESET handling synchronous"). For fabrics using transport_generic_free_cmd() in the usual way the double call to transport_lun_remove_cmd() doesn't harm, as transport_lun_remove_cmd() checks for this situation and does not release lun_ref twice. Link: https://lore.kernel.org/r/20200513153443.3554-1-bstroesser@ts.fujitsu.com Fixes: 2c9fa49e100f ("scsi: target/core: Make ABORT and LUN RESET handling synchronous") Cc: stable@vger.kernel.org Tested-by: Bryant G. Ly Reviewed-by: Bart van Assche Signed-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen --- drivers/target/target_core_transport.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c index 594b724bbf79..264a822c0bfa 100644 --- a/drivers/target/target_core_transport.c +++ b/drivers/target/target_core_transport.c @@ -3350,6 +3350,7 @@ static void target_tmr_work(struct work_struct *work) cmd->se_tfo->queue_tm_rsp(cmd); + transport_lun_remove_cmd(cmd); transport_cmd_check_stop_to_fabric(cmd); return;