[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aTGzL5t7Gu1tpebp@kbusch-mbp>
Date: Thu, 4 Dec 2025 09:13:35 -0700
From: Keith Busch <kbusch@...nel.org>
To: "Heyne, Maximilian" <mheyne@...zon.de>
Cc: Jens Axboe <axboe@...nel.dk>, Christoph Hellwig <hch@....de>,
Sagi Grimberg <sagi@...mberg.me>,
"linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] nvme: Let the blocklayer set timeouts for requests
On Thu, Dec 04, 2025 at 02:11:50PM +0000, Heyne, Maximilian wrote:
> @@ -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;
> }
I was trying to think of any in-kernel path using __submit_sync_cmd with
an IO queue, and quick search shows there's just one: zns report zones.
Everything else uses the admin queue, which doesn't have a sysfs tunable
for its request_queue's default timeout. All we have is the nvme module
parameter, which is writable after loading. Since that's the only way a
user can modify the default time for that queue, I think we need to
leave that req->timeout value as-is.
Powered by blists - more mailing lists