From: Maurizio Lombardi <mlombard@redhat.com>
To: kbusch@kernel.org
Cc: mheyne@amazon.de, emilne@redhat.com, jmeneghi@redhat.com,
linux-nvme@lists.infradead.org, dwagner@suse.de,
mlombard@bsdbackstore.eu
Subject: [PATCH RFC 1/5] nvme: Let the blocklayer set timeouts for requests
Date: Thu, 12 Feb 2026 13:09:47 +0100 [thread overview]
Message-ID: <20260212120951.79738-2-mlombard@redhat.com> (raw)
In-Reply-To: <20260212120951.79738-1-mlombard@redhat.com>
From: "Heyne, Maximilian" <mheyne@amazon.de>
When initializing an nvme request which is about to be send to the block
layer, we do not need to initialize its timeout. If it's left
uninitialized at 0 the block layer will use the request queue's timeout
in blk_add_timer (via nvme_start_request which is called from
nvme_*_queue_rq). These timeouts are setup to either NVME_IO_TIMEOUT or
NVME_ADMIN_TIMEOUT when the request queues were created.
Because the io_timeout of the IO queues can be modified via sysfs, the
following situation can occur:
1) NVME_IO_TIMEOUT = 30 (default module parameter)
2) nvme1n1 is probed. IO queues default timeout is 30 s
3) manually change the IO timeout to 90 s
echo 90000 > /sys/class/nvme/nvme1/nvme1n1/queue/io_timeout
4) Any call of __submit_sync_cmd on nvme1n1 to an IO queue will issue
commands with the 30 s timeout instead of the wanted 90 s which might
be more suitable for this device.
Commit 470e900c8036 ("nvme: refactor nvme_alloc_request") silently
changed the behavior for ioctl's already because it unconditionally
overrides the request's timeout that was set in nvme_init_request. If it
was unset by the user of the ioctl if will be overridden with 0 meaning
the block layer will pick the request queue's IO timeout.
Following up on that, this patch further improves the consistency of IO
timeout usage. However, there are still uses of NVME_IO_TIMEOUT which
could be inconsistent with what is set in the device's request_queue by
the user.
Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
---
drivers/nvme/host/core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 7bf228df6001..b9315f0abf80 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -724,10 +724,8 @@ void nvme_init_request(struct request *req, struct nvme_command *cmd)
struct nvme_ns *ns = req->q->disk->private_data;
logging_enabled = ns->head->passthru_err_log_enabled;
- req->timeout = NVME_IO_TIMEOUT;
} else { /* no queuedata implies admin queue */
logging_enabled = nr->ctrl->passthru_err_log_enabled;
- req->timeout = NVME_ADMIN_TIMEOUT;
}
if (!logging_enabled)
--
2.53.0
next prev parent reply other threads:[~2026-02-12 12:10 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-12 12:09 [PATCH RFC 0/5] nvme: Refactor and expose per-controller timeout configuration Maurizio Lombardi
2026-02-12 12:09 ` Maurizio Lombardi [this message]
2026-02-17 20:15 ` [PATCH RFC 1/5] nvme: Let the blocklayer set timeouts for requests Mohamed Khalfella
2026-02-18 12:19 ` Heyne, Maximilian
2026-02-12 12:09 ` [PATCH RFC 2/5] nvme: add sysfs attribute to change admin timeout per nvme controller Maurizio Lombardi
2026-02-17 20:17 ` Mohamed Khalfella
2026-02-18 12:40 ` Heyne, Maximilian
2026-02-18 14:49 ` Maurizio Lombardi
2026-02-18 18:00 ` Mohamed Khalfella
2026-02-19 16:16 ` Maurizio Lombardi
2026-02-12 12:09 ` [PATCH RFC 3/5] nvme: pci: use admin queue timeout over NVME_ADMIN_TIMEOUT Maurizio Lombardi
2026-02-17 20:22 ` Mohamed Khalfella
2026-02-18 13:10 ` Heyne, Maximilian
2026-02-18 13:32 ` Maurizio Lombardi
2026-02-12 12:09 ` [PATCH RFC 4/5] nvme: add sysfs attribute to change IO timeout per nvme controller Maurizio Lombardi
2026-02-17 20:25 ` Mohamed Khalfella
2026-02-18 13:28 ` Maurizio Lombardi
2026-02-18 17:54 ` Mohamed Khalfella
2026-02-19 17:22 ` Maurizio Lombardi
2026-02-20 12:47 ` Maurizio Lombardi
2026-02-20 17:53 ` Mohamed Khalfella
2026-02-23 10:36 ` Maurizio Lombardi
2026-02-18 17:58 ` Mohamed Khalfella
2026-02-12 12:09 ` [PATCH RFC 5/5] nvme: use per controller timeout waits over depending on global default Maurizio Lombardi
2026-02-17 20:29 ` Mohamed Khalfella
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=20260212120951.79738-2-mlombard@redhat.com \
--to=mlombard@redhat.com \
--cc=dwagner@suse.de \
--cc=emilne@redhat.com \
--cc=jmeneghi@redhat.com \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mheyne@amazon.de \
--cc=mlombard@bsdbackstore.eu \
/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