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 92B053CFF73 for ; Mon, 27 Jul 2026 19:19:40 +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=1785179982; cv=none; b=JVLOQ8nFwI/aI9iyYn8f9US6h4w5lLM7/E3+7OGtgBAshKJiWNlTF9pEZQnGEgsP1wmgyzGjVWSUDtBTvumvpaoJGxPgBDCL8tzXe3drbZdbN/iBsS1ZIi3yqI7DN9uH71V86p19GvpF8PtlL7NzLM1rkjKlCcqa+OTBtKcNRKA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785179982; c=relaxed/simple; bh=a6k92m799njvQd4gKgi7GkORaalE9OEtsv+rLd2Ozis=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jwimCvEHoaS/3N5K34NhpOnAyyCuLNUdDtepX9jY+hwd0/LMeFzWAnnw+C/uWEZVzhFkqP9QyScobzF1OwrFXjhRGMvn355WolDWHp8X/UHVstd3MojlzCFabIyc23zDxXlpewjMp+pR0VaRbTnCysf/BCCtShqhM+2lu8kT0VQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=WZs5+wd3; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="WZs5+wd3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C01C1F000E9; Mon, 27 Jul 2026 19:19:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1785179980; bh=V6q7CtGOOXMQTu5vNg7sea9a4Y5hhuIlF+3IDYB5PdI=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=WZs5+wd3ep+px3IOCgx12eVRKM1PP9E2Sfr9fhBlr9vz77DoiAhZvHOmWylhSicJ/ BgvpjJquBih399wjk5Jf6oX9GBVrA44Z29Mk+EeGwBuzVYNqyPtzJ6ORIg430U/xXw PrMXjsmOaTFW+Le8Xk2/CsYQuAIxTJhR02ljc7v4= Date: Mon, 27 Jul 2026 21:19:27 +0200 From: Greg Kroah-Hartman To: Keith Busch Cc: Hari Mishal , Jens Axboe , Christoph Hellwig , Sagi Grimberg , Hannes Reinecke , Kanchan Joshi , Nitesh Shetty , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] nvme: drop WARN_ON_ONCE on write_stream bounds check Message-ID: <2026072748-unpopular-onlooker-4a2b@gregkh> References: <20260725135111.14041-1-harimishal1@gmail.com> <20260725135111.14041-3-harimishal1@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 Mon, Jul 27, 2026 at 08:24:40AM -0600, Keith Busch wrote: > On Sat, Jul 25, 2026 at 03:51:11PM +0200, Hari Mishal wrote: > > write_stream is validated against bdev_max_write_streams() in both > > generic block direct I/O (block/fops.c) and F2FS before a bio > > carrying it is ever built, so write_stream > nr_plids shouldn't be > > reachable through any current legitimate path. The remaining users > > of bio->bi_write_stream elsewhere in the block layer only copy an > > already-validated value between bios (bio.c, blk-crypto-fallback.c) > > or compare it for merge eligibility (blk-merge.c); none of them > > introduce a new, unvalidated value. > > > > Using WARN_ON_ONCE as the backstop for that assumption isn't worth > > it given how many deployed systems run with panic-on-warn enabled; > > the existing graceful return BLK_STS_INVAL already handles it on > > its own. > > That's not a very good reason to remove a WARN_ON. You've left the check > in for a condition that should never happen, so when it does happen, > it'll be impossible to debug without the WARN. > > And the WARN also annotates the branch as unlikely, which is desirable > for this case. But, if it ever does happen, a WARN_ON will reboot the box, given that billions of Linux systems have panic-on-warn enabled. So if this can ever happen, just properly handle it and recover and don't loose user data. thanks, greg k-h