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 EC9A93002AB for ; Tue, 28 Jul 2026 10:34:37 +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=1785234879; cv=none; b=OuHLGw+wx6CGxgfV/7FU+ARqQL0jisGccW0M/m6Pxyaw0cAF7XGJp2BzCja5O61dylbL6C9vjUGekSRDSvn5Sks2XtED+mQ6CfSAOUUN3UniQVbw/S5CZvCAWcOu7Nl8qb8k3WE8IG6GzD3ckAF6zK7spDiGkZcTQxP/WvwVb0Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785234879; c=relaxed/simple; bh=vZhpEAvAfJ+olbi1XWI3GWFqaTEsu3W5EAis4Ltiqpk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=iI0TpwODdyIIGOcZauS44hAYdcUFuSDEadedw3xh63SauWzimN04rnrE8X0mOwPK/XYkamoP8S+ENAaHUFPQw/AM/Nxo3S606sz3dsNSz/temiIBdKeltp0z7z5ZOm39aqu7QZxohZrl/sPER9t1FsIlNx5UKdWzgU+Yb5ldIuo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=rO6E1lGG; 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="rO6E1lGG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C04541F00A3A; Tue, 28 Jul 2026 10:34:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1785234877; bh=FI6V0jJ8bPkXU47+DlmtFRU4ioIpKssIZvmexWj72wk=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=rO6E1lGGEtE0+Kon+Wl8fYx77twie7WQkferpRqgLDR4W6ZA/UOvuQKiXGuk62Crr nCcsscvxYSIOsJJhySae9bs4jCjvsgh+22ZgPT5E+BaFxXsYTdCtBLWLhvbwFTVIXI nKzCgWFr9aB9cjizjncMnDBJsgaIK27ptfXP50oM= Date: Tue, 28 Jul 2026 12:34:24 +0200 From: Greg Kroah-Hartman To: Keith Busch Cc: Christoph Hellwig , Hari Mishal , Jens Axboe , 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: <2026072833-anguished-grout-9533@gregkh> References: <20260725135111.14041-1-harimishal1@gmail.com> <20260725135111.14041-3-harimishal1@gmail.com> <2026072748-unpopular-onlooker-4a2b@gregkh> <2026072849-uproar-aqua-07c3@gregkh> <20260728051838.GA20593@lst.de> <2026072834-buffoon-entwine-ed16@gregkh> 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, Jul 28, 2026 at 03:46:50AM -0600, Keith Busch wrote: > On Tue, Jul 28, 2026 at 08:58:00AM +0200, Greg Kroah-Hartman wrote: > > I'm tired of it too, but again, if this can be hit by something a user > > does, it ends up being a DoS on the machine :( > > Why do you think has something to do with what a user does? The > filesystem and block layers own the write stream, and the contract is it > has to be within the reported limits. If it's not, there's a filesystem > bug; nothing to do with the user. I don't think this specific issue is something that a user can trigger, as I really don't know how this code path works. I was making the larger statement of "If a user can hit a WARN_ON() kernel call, then it should be fixed to properly handle that logic." thanks, greg k-h