From: Alan Stern <stern@rowland.harvard.edu>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Martin Kepplinger <martin.kepplinger@puri.sm>,
Can Guo <cang@codeaurora.org>,
linux-scsi@vger.kernel.org, linux-block@vger.kernel.org,
kernel@puri.sm
Subject: Re: [PATCH] block: Fix bug in runtime-resume handling
Date: Sat, 29 Aug 2020 21:06:26 -0400 [thread overview]
Message-ID: <20200830010626.GA507988@rowland.harvard.edu> (raw)
In-Reply-To: <eb208ee3-b94b-c020-990f-c7151ecaae03@acm.org>
On Sat, Aug 29, 2020 at 05:38:50PM -0700, Bart Van Assche wrote:
> On 2020-08-29 11:56, Alan Stern wrote:
> > A third possibility is the approach I outlined before, adding a
> > BLK_MQ_REQ_PM flag. But to avoid the deadlock you pointed out, I would
> > make blk_queue_enter smarter about whether to postpone a request. The
> > logic would go like this:
> >
> > If !blk_queue_pm_only:
> > Allow
> > If !BLK_MQ_REQ_PREEMPT:
> > Postpone
> > If q->rpm_status is RPM_ACTIVE:
> > Allow
> > If !BLK_MQ_REQ_PM:
> > Postpone
> > If q->rpm_status is RPM_SUSPENDED:
> > Postpone
> > Else:
> > Allow
> >
> > The assumption here is that the PREEMPT flag is set whenever the PM flag
> > is.
>
> Hi Alan,
>
> Although interesting, these solutions sound like workarounds to me. How
> about fixing the root cause by modifying the SCSI DV implementation such
> that it doesn't use scsi_device_quiesce() anymore()? That change would
> allow to remove BLK_MQ_REQ_PREEMPT / RQF_PREEMPT from the block layer and
> move these flags into the SCSI and IDE code.
That's a perfectly reasonable approach, but I have no idea how to do it.
Any suggestions?
Alan Stern
prev parent reply other threads:[~2020-08-30 1:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <9b80ca7c-39f8-e52d-2535-8b0baf93c7d1@puri.sm>
[not found] ` <425990b3-4b0b-4dcf-24dc-4e7e60d5869d@puri.sm>
[not found] ` <20200807143002.GE226516@rowland.harvard.edu>
[not found] ` <b0abab28-880e-4b88-eb3c-9ffd927d1ed9@puri.sm>
[not found] ` <20200808150542.GB256751@rowland.harvard.edu>
[not found] ` <d3b6f7b8-5345-1ae1-4f79-5dde226e74f1@puri.sm>
[not found] ` <20200809152643.GA277165@rowland.harvard.edu>
[not found] ` <60150284-be13-d373-5448-651b72a7c4c9@puri.sm>
[not found] ` <20200810141343.GA299045@rowland.harvard.edu>
[not found] ` <6f0c530f-4309-ab1e-393b-83bf8367f59e@puri.sm>
2020-08-23 14:57 ` [PATCH] block: Fix bug in runtime-resume handling Alan Stern
2020-08-24 17:48 ` Bart Van Assche
2020-08-24 20:13 ` Alan Stern
2020-08-26 7:48 ` Martin Kepplinger
2020-08-27 17:42 ` Martin Kepplinger
2020-08-27 20:29 ` Alan Stern
2020-08-29 7:24 ` Martin Kepplinger
2020-08-29 15:26 ` Alan Stern
2020-08-29 16:33 ` Martin Kepplinger
2020-08-29 18:56 ` Alan Stern
2020-08-30 0:38 ` Bart Van Assche
2020-08-30 1:06 ` Alan Stern [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200830010626.GA507988@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=bvanassche@acm.org \
--cc=cang@codeaurora.org \
--cc=kernel@puri.sm \
--cc=linux-block@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.kepplinger@puri.sm \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox