From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 46A263A2E28 for ; Thu, 9 Jul 2026 18:17:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783621068; cv=none; b=q6Pe6TWO6yhjD6oUMum8G0XJCGJNALyagdbpZSbCSFNtRmrGSykXfTi+JKkCAM5rvBx9opbtWY6z0JCPEs40Yol27mdsRRf5Xz18wHE0yIzwYJ1p9jn0c0pY47znN2JrgCPdrYTJ2ubGw3+ZCY0VALleB+udrTRIckZx/WcCsOo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783621068; c=relaxed/simple; bh=VoCILAfqxmuIH4GU6ncp9t33yDiAyCSEfZ159fmJ7Hw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ekuqGgOgiswxl0ndFvujCQsWjm8W045VvBL9fNXrBEg54LRIT4GIFMaBM55tXW3HFrLuOGJEezRcUng1U1d8SYvN9XFscW80yFB9VCN+qYfuL+XvLQqVFlLxHpD7sHknRnvCRwqugLxJ7jHhk58ApN9HjcqdfUBLXogL8VkRW+c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IZDqFWGe; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IZDqFWGe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 818C81F000E9; Thu, 9 Jul 2026 18:17:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783621066; bh=BApKWh98f8P6jTcZKKxbTt2xnuQNFrkhYUwkGsfJr3g=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=IZDqFWGeNzg2/HaC28FeDvJ6hd+C+3+3gv+/EfvJTv9+yYPMc0lObxWcRVKXjfmR1 uBVvYcIpM8qFcBkn8kQ3r6AQxyYgSqWtxAcv3vjFptcOmLoORW8sz1tGa1El8lJCrM M5gZeN2jV5bWgQcykmWmaGAtWhTjeLwBfWBF9C7BX/7MLnjk8/IHWu+wl0VtNI6w3f GVwGkVGhibsaLvOZXLoOLo2YGcRbCntSHbTDVnR2GOoNQ9B6hFMEnfDnim0Dv9MfuE sq2JkoB2AtkFwo0fwmAk/yKgqpnAhChCyqdIcQbTb3MacAln6sJJrfwAFLhq9M/Q9F g88XfV3WTL8zw== Date: Thu, 9 Jul 2026 12:17:45 -0600 From: Keith Busch To: Chao S Cc: Jens Axboe , Christoph Hellwig , Sagi Grimberg , Chaitanya Kulkarni , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Sungwoo Kim , Dave Tian , Weidong Zhu Subject: Re: [PATCH] nvme: bound the freeze drain in passthrough commands Message-ID: References: <20260527055923.456769-1-coshi036@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Jun 23, 2026 at 06:28:49PM -0400, Chao S wrote: > Timeout fires, abort is accepted, reset starts, reset reaches the > "IO queues lost" branch (drivers/nvme/host/pci.c). Then nvme_reset_work > itself blocks at > > nvme_mark_namespaces_dead -> blk_mark_disk_dead -> blk_report_disk_dead > -> bdev_mark_dead(bdev, true) -> sync_blockdev -> folio_wait_writeback > > i.e. the unconditional sync_blockdev in bdev_mark_dead's bare-bdev > else-branch (block/bdev.c) is itself waiting on the writeback that the > reset was supposed to drain. But sync_blockdev is *not* unconditional. It's conditional on this not being a surprise removal, and blk_mark_disk_dead() is considered a surprise, so I am not sure you've identified the right sequence. > So in this report, the IO timeout did its job, but the reset that the > timeout kicks off cannot complete, and nvme_passthru_start (which is > already in nvme_wait_freeze at this point) has no way to back out. I guess what may have happened is that the timeout handler requeued the IO on a quiesced queue so it does reach frozen state. Just move the unquiesce to before the call to nvme_mark_namespaces_dead(). But I still don't think it should be needed because nvme_mark_namespaces_dead() shouldn't block. > 1. The reset path has several ways to fail to drain in > nvme_io_timeout: abort can be rejected, the admin tag for abort > can be unavailable, the controller can be wedged before abort > lands, an in-progress reset can outlast nvme_io_timeout, or (as > here) reset itself can block. Each leaves nvme_passthru_start > waiting forever, holding ctrl->scan_lock + subsys->lock + every > namespace's freeze ref, which then fans out on bd_disk->open_mutex > via any concurrent bdev_open/release or BLKRRPART. No, that's not what happens. If abort fails, then the command times out a 2nd time, then we escalate to reset. If we can't get an abort tag, then that means an abort is in progress. If it doesn't completely timely, then we escalate to reset. > 2. The same pattern is already established in the tree. pci shutdown > (drivers/nvme/host/pci.c), nvme-tcp reset, nvme-rdma reset, > nvme-apple, and Daniel Wagner's 2021 nvme-fc series > (20210818120530.130501-1-dwagner@suse.de) all use > nvme_wait_freeze_timeout(NVME_IO_TIMEOUT) for exactly this reason. > nvme_passthru_start is the only userspace-reachable caller still > on the unbounded variant. Those are for entirely different cases where we're in the last line of recovery and have to guarantee forward progress.