- 27 Jan, 2022 1 commit
-
-
Alan Stern authored
[ Upstream commit 6e1fcab0 ] John Garry reported a deadlock that occurs when trying to access a runtime-suspended SATA device. For obscure reasons, the rescan procedure causes the link to be hard-reset, which disconnects the device. The rescan tries to carry out a runtime resume when accessing the device. scsi_rescan_device() holds the SCSI device lock and won't release it until it can put commands onto the device's block queue. This can't happen until the queue is successfully runtime-resumed or the device is unregistered. But the runtime resume fails because the device is disconnected, and __scsi_remove_device() can't do the unregistration because it can't get the device lock. The best way to resolve this deadlock appears to be to allow the block queue to start running again even after an unsuccessful runtime resume. The idea is that the driver or the SCSI error handler will need to be able to use the queue to resolve the runtime resume failure. This patch removes the err argument to blk_post_runtime_resume() and makes the routine act as though the resume was successful always. This fixes the deadlock. Link: https://lore.kernel.org/r/1639999298-244569-4-git-send-email-chenxiang66@hisilicon.com Fixes: e27829dc ("scsi: serialize ->rescan against ->remove") Reported-and-tested-by:
John Garry <john.garry@huawei.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
- 06 Jan, 2021 1 commit
-
-
Bart Van Assche authored
commit fa4d0f19 upstream. With the current implementation the following race can happen: * blk_pre_runtime_suspend() calls blk_freeze_queue_start() and blk_mq_unfreeze_queue(). * blk_queue_enter() calls blk_queue_pm_only() and that function returns true. * blk_queue_enter() calls blk_pm_request_resume() and that function does not call pm_request_resume() because the queue runtime status is RPM_ACTIVE. * blk_pre_runtime_suspend() changes the queue status into RPM_SUSPENDING. Fix this race by changing the queue runtime status into RPM_SUSPENDING before switching q_usage_counter to atomic mode. Link: https://lore.kernel.org/r/20201209052951.16136-2-bvanassche@acm.org Fixes: 986d413b ("blk-mq: Enable support for runtime power management") Cc: Ming Lei <ming.lei@redhat.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: stable <stable@vger.kernel.org> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
Jens Axboe <axboe@kernel.dk> Acked-by:
Stanley Chu <stanley.chu@mediatek.com> Co-developed-by:
Can Guo <cang@codeaurora.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 25 Jul, 2020 1 commit
-
-
Alan Stern authored
Commit 05d18ae1 ("scsi: pm: Balance pm_only counter of request queue during system resume") fixed a problem in the block layer's runtime-PM code: blk_set_runtime_active() failed to call blk_clear_pm_only(). However, the commit's implementation was awkward; it forced the SCSI system-resume handler to choose whether to call blk_post_runtime_resume() or blk_set_runtime_active(), depending on whether or not the SCSI device had previously been runtime suspended. This patch simplifies the situation considerably by adding the missing function call directly into blk_set_runtime_active() (under the condition that the queue is not already in the RPM_ACTIVE state). This allows the SCSI routine to revert back to its original form. Furthermore, making this change reveals that blk_post_runtime_resume() (in its success pathway) does exactly the same thing as blk_set_runtime_active(). The duplicate code is easily removed by making one routine call the other. No functional changes are intended. Link: https://lore.kernel.org/r/20200706151436.GA702867@rowland.harvard.edu CC: Can Guo <cang@codeaurora.org> CC: Bart Van Assche <bvanassche@acm.org> Reviewed-by:
-
- 12 Sep, 2019 1 commit
-
-
Stanley Chu authored
Some devices may skip blk_pm_runtime_init() and have null pointer in its request_queue->dev. For example, SCSI devices of UFS Well-Known LUNs. Currently the null pointer is checked by the user of blk_set_runtime_active(), i.e., scsi_dev_type_resume(). It is better to check it by blk_set_runtime_active() itself instead of by its users. Signed-off-by:
-
- 15 Nov, 2018 1 commit
-
-
Christoph Hellwig authored
With the legacy request path gone there is no good reason to keep queue_lock as a pointer, we can always use the embedded lock now. Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
-
- 26 Sep, 2018 3 commits
-
-
Bart Van Assche authored
Now that the blk-mq core processes power management requests (marked with RQF_PREEMPT) in other states than RPM_ACTIVE, enable runtime power management for blk-mq. Signed-off-by:
Ming Lei <ming.lei@redhat.com> Reviewed-by:
-
Bart Van Assche authored
Instead of allowing requests that are not power management requests to enter the queue in runtime suspended status (RPM_SUSPENDED), make the blk_get_request() caller block. This change fixes a starvation issue: it is now guaranteed that power management requests will be executed no matter how many blk_get_request() callers are waiting. For blk-mq, instead of maintaining the q->nr_pending counter, rely on q->q_usage_counter. Call pm_runtime_mark_last_busy() every time a request finishes instead of only if the queue depth drops to zero. Signed-off-by:
-
Bart Van Assche authored
Move the code for runtime power management from blk-core.c into the new source file blk-pm.c. Move the corresponding declarations from <linux/blkdev.h> into <linux/blk-pm.h>. For CONFIG_PM=n, leave out the declarations of the functions that are not used in that mode. This patch not only reduces the number of #ifdefs in the block layer core code but also reduces the size of header file <linux/blkdev.h> and hence should help to reduce the build time of the Linux kernel if CONFIG_PM is not defined. Signed-off-by:
-
