From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fra-out-007.esa.eu-central-1.outbound.mail-perimeter.amazon.com (fra-out-007.esa.eu-central-1.outbound.mail-perimeter.amazon.com [3.75.33.185]) (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 B344D2D0601 for ; Tue, 2 Dec 2025 17:52:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=3.75.33.185 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764697935; cv=none; b=bk74OsM81f8QhDR3l7Ps2ykQDh8rz+S55hFRZvlmA8M5UPk/rREFCGHmWb8KB0qMl9JHd45+a7/eMmpsrVEPuyiyb5od7nrjrfAavY9fJ3dtk8Ux3YyLQsujsLWZ9bq8Hs0wsV0FRIfUF1Wvm32bZrDBnRairN9+l7SkK7Tx8Rg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764697935; c=relaxed/simple; bh=rnTiWxJ5DT88S+do0yuj9wbtwms3PaJWJHz6PlSGVcY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=Fai0UkL9AUN4mlPI6ZU8qsasrUP8nap9DPxKzcXYvZwzDQPeDSzc7bIHAvY8hgWibAVk5MJxvm/PPN2wSXvaXUWAknCSdAW+72rlslNuuMgZrL47OFjrkr7E67zQyTdR+EdmvauadqsPexH1IHL4kHhwVCAzozqqel18jxjS68w= 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=YNDOeY8S; arc=none smtp.client-ip=3.75.33.185 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="YNDOeY8S" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.de; i=@amazon.de; q=dns/txt; s=amazoncorp2; t=1764697932; x=1796233932; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:mime-version: content-transfer-encoding; bh=sq3/uyeuFrXhQAVmVJjbGubVsI3fsJsI0zwIy0cR2aY=; b=YNDOeY8SsGE0EwVksH2OrEckW89+vn9MKTePPb/3QZGeln6sY3LV95RD e3Ncgy9C8C4J9Pvz32t6BpMDkimQqoGsv/xIDCpqZ+o67b/KCb1rlIGZj lpAcDxeXltjZTvtTONgcAb0eiEXhplvEfGqVv9KBOMI7wlF9qJydjjjut VITjvefZ8f43BJf3PEQCke8IzPVGyZJ/Tcm1id2BogUj8/FUzZ9B+4DRH 5Rdp3q6WgRnPrcYzC08XpsSWR9q798O0II0UyKFvOues5fnE9t3q0nQTy jUsIWrYE5RWps3joXI52T50Pk4UquUhyNarxpjAkCJDk8eEPdlprP/Gk1 A==; X-CSE-ConnectionGUID: PEKxHDPZTNWfnPTkd2uiww== X-CSE-MsgGUID: iTmpsolST/OALeUqjMdEag== X-IronPort-AV: E=Sophos;i="6.20,243,1758585600"; d="scan'208";a="6132405" Received: from ip-10-6-11-83.eu-central-1.compute.internal (HELO smtpout.naws.eu-central-1.prod.farcaster.email.amazon.dev) ([10.6.11.83]) by internal-fra-out-007.esa.eu-central-1.outbound.mail-perimeter.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2025 17:51:44 +0000 Received: from EX19MTAEUC002.ant.amazon.com [54.240.197.228:19767] by smtpin.naws.eu-central-1.prod.farcaster.email.amazon.dev [10.0.46.211:2525] with esmtp (Farcaster) id 59332ee5-d083-42ff-8e8e-68e6e0ab314c; Tue, 2 Dec 2025 17:51:44 +0000 (UTC) X-Farcaster-Flow-ID: 59332ee5-d083-42ff-8e8e-68e6e0ab314c Received: from EX19D008EUC004.ant.amazon.com (10.252.51.148) by EX19MTAEUC002.ant.amazon.com (10.252.51.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.29; Tue, 2 Dec 2025 17:51:36 +0000 Received: from EX19D008EUC001.ant.amazon.com (10.252.51.165) by EX19D008EUC004.ant.amazon.com (10.252.51.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.29; Tue, 2 Dec 2025 17:51:36 +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; Tue, 2 Dec 2025 17:51:36 +0000 From: "Heyne, Maximilian" To: Keith Busch CC: Jens Axboe , Christoph Hellwig , "Sagi Grimberg" , "linux-nvme@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] nvme: Let the blocklayer set timeouts for requests Thread-Topic: [PATCH] nvme: Let the blocklayer set timeouts for requests Thread-Index: AQHcY7RNpRG0rKo2fE2fBNMXvetFmw== Date: Tue, 2 Dec 2025 17:51:36 +0000 Message-ID: <20251202-78-chops-11b0312d@mheyne-amazon> References: <20251202-arrow-debris-c25524e1@mheyne-amazon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <163DC25D524D114CA2879E5DC661D2C5@amazon.com> 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 On Tue, Dec 02, 2025 at 10:39:11AM -0700, Keith Busch wrote: > On Tue, Dec 02, 2025 at 01:58:19PM +0000, Heyne, Maximilian wrote: > > 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 actually 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) nvme zns report-zones /dev/nvme1n1 > > This command issues IO commands with timeout 30 s instead of the > > wanted 90 s which might be more suitable for this device. > = > Does this example really use 30s, though? User space commands should be > going through nvme_submit_user_cmd(), which overrides the timeout set > from the nvme_init_request with whatever the user requested (usually 0). You're right. I actually worked on multiple (older) kernel versions and forgot about this case. It was actually commit 470e900c8036ff ("nvme: refactor nvme_alloc_request") which subtly changed the behavior but only for the ioctl case. So ioctl's are fine then but, for example, everything which goes via nvme_submit_sync_cmd shows the issue. So we need to update the commit message accordingly. Sorry for that. I'll give it a day or two for further comments on this patch and then send it with a more correct message. 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