From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Bart Van Assche <bvanassche@acm.org>,
"David S . Miller" <davem@davemloft.net>,
Alan Stern <stern@rowland.harvard.edu>,
Can Guo <cang@codeaurora.org>,
Stanley Chu <stanley.chu@mediatek.com>,
Ming Lei <ming.lei@redhat.com>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
Christoph Hellwig <hch@lst.de>, Hannes Reinecke <hare@suse.de>,
Jens Axboe <axboe@kernel.dk>,
"Martin K . Petersen" <martin.petersen@oracle.com>,
Sasha Levin <sashal@kernel.org>,
linux-ide@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: [PATCH AUTOSEL 4.14 3/6] scsi: ide: Do not set the RQF_PREEMPT flag for sense requests
Date: Mon, 4 Jan 2021 20:00:09 -0500 [thread overview]
Message-ID: <20210105010012.3954626-3-sashal@kernel.org> (raw)
In-Reply-To: <20210105010012.3954626-1-sashal@kernel.org>
From: Bart Van Assche <bvanassche@acm.org>
[ Upstream commit 96d86e6a80a3ab9aff81d12f9f1f2a0da2917d38 ]
RQF_PREEMPT is used for two different purposes in the legacy IDE code:
1. To mark power management requests.
2. To mark requests that should preempt another request. An (old)
explanation of that feature is as follows: "The IDE driver in the Linux
kernel normally uses a series of busywait delays during its
initialization. When the driver executes these busywaits, the kernel
does nothing for the duration of the wait. The time spent in these
waits could be used for other initialization activities, if they could
be run concurrently with these waits.
More specifically, busywait-style delays such as udelay() in module
init functions inhibit kernel preemption because the Big Kernel Lock is
held, while yielding APIs such as schedule_timeout() allow
preemption. This is true because the kernel handles the BKL specially
and releases and reacquires it across reschedules allowed by the
current thread.
This IDE-preempt specification requires that the driver eliminate these
busywaits and replace them with a mechanism that allows other work to
proceed while the IDE driver is initializing."
Since I haven't found an implementation of (2), do not set the PREEMPT flag
for sense requests. This patch causes sense requests to be postponed while
a drive is suspended instead of being submitted to ide_queue_rq().
If it would ever be necessary to restore the IDE PREEMPT functionality,
that can be done by introducing a new flag in struct ide_request.
Link: https://lore.kernel.org/r/20201209052951.16136-4-bvanassche@acm.org
Cc: David S. Miller <davem@davemloft.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Can Guo <cang@codeaurora.org>
Cc: Stanley Chu <stanley.chu@mediatek.com>
Cc: Ming Lei <ming.lei@redhat.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/ide/ide-atapi.c | 1 -
drivers/ide/ide-io.c | 5 -----
2 files changed, 6 deletions(-)
diff --git a/drivers/ide/ide-atapi.c b/drivers/ide/ide-atapi.c
index 0e6bc631a1caf..215558c947def 100644
--- a/drivers/ide/ide-atapi.c
+++ b/drivers/ide/ide-atapi.c
@@ -213,7 +213,6 @@ void ide_prep_sense(ide_drive_t *drive, struct request *rq)
sense_rq->rq_disk = rq->rq_disk;
sense_rq->cmd_flags = REQ_OP_DRV_IN;
ide_req(sense_rq)->type = ATA_PRIV_SENSE;
- sense_rq->rq_flags |= RQF_PREEMPT;
req->cmd[0] = GPCMD_REQUEST_SENSE;
req->cmd[4] = cmd_len;
diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
index 3a234701d92c4..7f34dc49c9b5f 100644
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -531,11 +531,6 @@ void do_ide_request(struct request_queue *q)
* above to return us whatever is in the queue. Since we call
* ide_do_request() ourselves, we end up taking requests while
* the queue is blocked...
- *
- * We let requests forced at head of queue with ide-preempt
- * though. I hope that doesn't happen too much, hopefully not
- * unless the subdriver triggers such a thing in its own PM
- * state machine.
*/
if ((drive->dev_flags & IDE_DFLAG_BLOCKED) &&
ata_pm_request(rq) == 0 &&
--
2.27.0
next prev parent reply other threads:[~2021-01-05 1:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-05 1:00 [PATCH AUTOSEL 4.14 1/6] workqueue: Kick a worker based on the actual activation of delayed works Sasha Levin
2021-01-05 1:00 ` [PATCH AUTOSEL 4.14 2/6] scsi: ufs-pci: Ensure UFS device is in PowerDown mode for suspend-to-disk ->poweroff() Sasha Levin
2021-01-05 1:00 ` Sasha Levin [this message]
2021-01-05 1:00 ` [PATCH AUTOSEL 4.14 4/6] kdev_t: always inline major/minor helper functions Sasha Levin
2021-01-05 1:00 ` [PATCH AUTOSEL 4.14 5/6] lib/genalloc: fix the overflow when size is too big Sasha Levin
2021-01-05 1:00 ` [PATCH AUTOSEL 4.14 6/6] depmod: handle the case of /sbin/depmod without /sbin in PATH Sasha Levin
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=20210105010012.3954626-3-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=cang@codeaurora.org \
--cc=davem@davemloft.net \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=martin.petersen@oracle.com \
--cc=ming.lei@redhat.com \
--cc=rafael.j.wysocki@intel.com \
--cc=stable@vger.kernel.org \
--cc=stanley.chu@mediatek.com \
--cc=stern@rowland.harvard.edu \
/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