From nobody Sat Feb 7 23:48:05 2026 Received: from fra-out-006.esa.eu-central-1.outbound.mail-perimeter.amazon.com (fra-out-006.esa.eu-central-1.outbound.mail-perimeter.amazon.com [18.197.217.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D281523EA95 for ; Thu, 4 Dec 2025 14:12:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=18.197.217.180 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764857531; cv=none; b=HQVE0/GhOPUIbA9SMJewXZ0iDromK/gHYiSXf42p8nkHX72d5gHHWQrKhvksvnw3IOkrdk+H+wrVMEIfscUPGrJneAKozc0XCvOUb35mLICYYFka4VMViYWEJeZwNp2c6u5Z8mFp+RU6S0dcM7rTb0YQtsWAC1/W+tgQkI03CBU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764857531; c=relaxed/simple; bh=nEPWz3m05JljZ93xTZwt0P8BGUkTmbb8lfq5Dhg2sFE=; h=From:CC:Subject:Date:Message-ID:Content-Type:MIME-Version; b=ivfnbo+bMN1eS8XGb0qb+XQPdlqzgGq3rl0RanJbgQQb3xbC+WLWuLioafuJADzDUHfSNCZ9F1BDsbaJ4fcWZGtCRmw7Rs/BeKSMJ/ARvtrjji4qAO+R5Q0WOSY5PuzWb7TaWQLQ4vYQpKWIcfLSoYh3u3KWjGIQPt5fg86mNQs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.de; spf=pass smtp.mailfrom=amazon.de; dkim=pass (2048-bit key) header.d=amazon.de header.i=@amazon.de header.b=EijaqfJw; arc=none smtp.client-ip=18.197.217.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=amazon.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=amazon.de header.i=@amazon.de header.b="EijaqfJw" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.de; i=@amazon.de; q=dns/txt; s=amazoncorp2; t=1764857529; x=1796393529; h=from:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=zHAkc3aSRt4H58MO7hMNVzjrvfIHCs6a3GVXcfFgctw=; b=EijaqfJwEe7lGGcD6oxy1hXK5N2Loz7rWYAtmsJR4uDVF0KMMqtIay53 uBP5CMcJc6q3NbCAZ2ki2xWulNj49E2CHFOcsikcxmMq2MDLLeXU9aREq UOi7VzQjSE5plFVn6+vjkEzw3VGwWGJcA4L+WQ6uxJ0BVf5L5zOVu03M6 MV0yFeoh6EeUHagMGRwlIGun/4U7/jdXbPsJnI0OMZ/UafQ9gECqFHO2U TBCOa4zHTYp+rJNZyUXRo/iK6sr/hSZ05xOZ/0eUqsWGAlzw9M+yW1Gi8 6zIohgSdjCpLwRIasNFtK8TyqWXpfRZ43sE9uzqxkOZA9TyeLQZiCqn7n w==; X-CSE-ConnectionGUID: 6v7uMLzkQECqsHpUxOH2jw== X-CSE-MsgGUID: yMfl4VxmQLWEY7OOKlSdqA== X-IronPort-AV: E=Sophos;i="6.20,249,1758585600"; d="scan'208";a="6237372" Received: from ip-10-6-3-216.eu-central-1.compute.internal (HELO smtpout.naws.eu-central-1.prod.farcaster.email.amazon.dev) ([10.6.3.216]) by internal-fra-out-006.esa.eu-central-1.outbound.mail-perimeter.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Dec 2025 14:11:51 +0000 Received: from EX19MTAEUA002.ant.amazon.com [54.240.197.232:13953] by smtpin.naws.eu-central-1.prod.farcaster.email.amazon.dev [10.0.24.148:2525] with esmtp (Farcaster) id 5c9fd160-a5ea-47ec-9c7e-ac7ae8294279; Thu, 4 Dec 2025 14:11:50 +0000 (UTC) X-Farcaster-Flow-ID: 5c9fd160-a5ea-47ec-9c7e-ac7ae8294279 Received: from EX19D008EUC002.ant.amazon.com (10.252.51.146) by EX19MTAEUA002.ant.amazon.com (10.252.50.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.29; Thu, 4 Dec 2025 14:11:50 +0000 Received: from EX19D008EUC001.ant.amazon.com (10.252.51.165) by EX19D008EUC002.ant.amazon.com (10.252.51.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.29; Thu, 4 Dec 2025 14:11:50 +0000 Received: from EX19D008EUC001.ant.amazon.com ([fe80::9611:c62b:a7ba:aee1]) by EX19D008EUC001.ant.amazon.com ([fe80::9611:c62b:a7ba:aee1%3]) with mapi id 15.02.2562.029; Thu, 4 Dec 2025 14:11:50 +0000 From: "Heyne, Maximilian" CC: "Heyne, Maximilian" , Keith Busch , Jens Axboe , Christoph Hellwig , Sagi Grimberg , "linux-nvme@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: [PATCH v2] nvme: Let the blocklayer set timeouts for requests Thread-Topic: [PATCH v2] nvme: Let the blocklayer set timeouts for requests Thread-Index: AQHcZSfu6ypIT7DcmUS6OdgGRPM68A== Date: Thu, 4 Dec 2025 14:11:50 +0000 Message-ID: <20251204-tests-bryce-8b3b2823@mheyne-amazon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 =3D 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 --- 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 nvm= e_command *cmd) struct nvme_ns *ns =3D req->q->disk->private_data; =20 logging_enabled =3D ns->head->passthru_err_log_enabled; - req->timeout =3D NVME_IO_TIMEOUT; } else { /* no queuedata implies admin queue */ logging_enabled =3D nr->ctrl->passthru_err_log_enabled; - req->timeout =3D NVME_ADMIN_TIMEOUT; } =20 if (!logging_enabled) --=20 2.47.3 Amazon Web Services Development Center Germany GmbH Tamara-Danz-Str. 13 10243 Berlin Geschaeftsfuehrung: Christian Schlaeger, Christof Hellmis Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597