From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 9A4241FB1 for ; Mon, 20 Apr 2026 14:51:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776696673; cv=none; b=JhxX9NhSparocHwWwYK7VkNPvGRwd/Bcq0X7U2aC5FkBV/SfO4AhsPvrBAFKgTyNiDgq9oDHxErQk1PxUhfpXLEG3X6lRM4eXHsjd0CUfjNcngI/S74FWTdJzb5r1iN7Q5N0EGWs1z8lRRyH/Ss9UzYBa+LPZSFNDOwUYmuc+as= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776696673; c=relaxed/simple; bh=8UoUFrvUJb5Thy6ctrITs58pMyDxujdI0HAy+0ogeVU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ear9gRuvQIuUkpOeTx/EbMvm+6dNEXsngUwAarOPQ3frSneImF7QF/VSrnj9Bzw/C5R+vIfGgcig4BIia+I5cjD8NUFE7EjqmgjTbJh6M1dPd2KJ6MuCeG425mDaMSwsSwcuEoE79PtV3v4aR1+v4mj04uLzIZ+Omfth4KqRHMs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=P6y50vLX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="P6y50vLX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5984C19425; Mon, 20 Apr 2026 14:51:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776696673; bh=8UoUFrvUJb5Thy6ctrITs58pMyDxujdI0HAy+0ogeVU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=P6y50vLXRB+Lqv96OF0AqvjMcDtJWtzzpvZBKZwdptikQvPeVPipvWpelAypa2RQ7 DRiLeiZB7M1GFAds3Y5tm/ioQRnxvLD+0KleMhAcI/krJJp+eiRuiCWvFfte7dCGBh F996n9wYaXDJgfbVhEgGTsHaJ4FDidu2gGSwYD5h7q9kUkuhKHsFudV0KTjfbOQoU0 /nPPkDWaHrPnVEKnP9W0rWValPPbpz4SJnFS5xGodENCV2xSCaRyyV99tJGtRFr9Ao r+v8cig1EcmZgX5mc/8T9YhUoX1iCtASgX3AHkGXqND6XGRHQbkPM0i90veseshnpa P8dPlWJicuqXw== Date: Mon, 20 Apr 2026 08:51:11 -0600 From: Keith Busch To: Chao Shi Cc: Jens Axboe , Christoph Hellwig , Sagi Grimberg , Daniel Wagner , Hannes Reinecke , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Sungwoo Kim , Dave Tian , Weidong Zhu Subject: Re: [PATCH] nvme: core: reject invalid LBA data size from Identify Namespace Message-ID: References: <20260418042835.420281-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: <20260418042835.420281-1-coshi036@gmail.com> On Sat, Apr 18, 2026 at 12:28:34AM -0400, Chao Shi wrote: > memflags = blk_mq_freeze_queue(ns->disk->queue); > + if (id->lbaf[lbaf].ds < SECTOR_SHIFT || > + check_shl_overflow(le64_to_cpu(id->nsze), > + id->lbaf[lbaf].ds - SECTOR_SHIFT, > + &capacity)) { > + dev_warn_once(ns->ctrl->device, > + "invalid LBA data size %u, skipping namespace\n", > + id->lbaf[lbaf].ds); > + ret = -EIO; I think ENODEV is more appropriate errno. > + blk_mq_unfreeze_queue(ns->disk->queue, memflags); > + goto out; I don't see any particular reason why we shouldn't validate this value before starting the queue updates and freezing the queue, like we for the ncap field up higher. Doing that would make the error case much simpler. Case in point, you're missing the corresponding queue_limits_cancel_update() for this error case. > + } > ns->head->lba_shift = id->lbaf[lbaf].ds; > ns->head->nuse = le64_to_cpu(id->nuse); > - capacity = nvme_lba_to_sect(ns->head, le64_to_cpu(id->nsze)); > nvme_set_ctrl_limits(ns->ctrl, &lim, false); > nvme_configure_metadata(ns->ctrl, ns->head, id, nvm, info); > nvme_set_chunk_sectors(ns, id, &lim); > -- > 2.43.0 >