From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D0C5E3451D6 for ; Tue, 24 Mar 2026 07:05:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774335962; cv=none; b=dOo9vHkWx9HNIv7zku6wiNsn0kmTSE59zD2ZpPkdv2W59vW+lBGrot2SrR852N/DDZLkYnYjDeJ9DnCFe/03R08H2Z7wHI0XHTIYYvjF4k+fc8XNWdktZLcLG2pp7JUmhANYXztdM3t/hXsudzGOeu2QArvBCi0yoFbX/U+YWFE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774335962; c=relaxed/simple; bh=bgztSNqcTeotlUR6QBOXzJ43X43jR0JVIwponN08oCs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=atyG19cyH/mYbTF6X2plAT+LBSBAHyK4pXpPQt/iVsgm5V6Ywj/o5C+R9DP5APXXLUMPEDAYnaIdrcyMnFByOaoKRo0srUY6QRDAz3Ba6OqCDZlv1nDZPpSn81SUc6DxTMa/ZiciOxxg662PonNWEdlTn0/51KTol+3rNdKC3+Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=vVif1RVG; arc=none smtp.client-ip=209.85.128.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="vVif1RVG" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-483487335c2so38659445e9.2 for ; Tue, 24 Mar 2026 00:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1774335953; x=1774940753; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=eJqRw8wJksOuCmbVXg0UKSzuvntxhtDkZlZiq7BcWIo=; b=vVif1RVGObkx7/CqcFX8C3rpO0AiTMwQ9raed0eCApqbEA7Y8NnsnQ1xgwjQofe50a yPvQ/dPEgAzevxq+ClTRQf+gAy4/yMJai0soqyVcDPKmfg1BUt1QSTi71x46ZxlfFghi 0WmJLAeocycwDhQJyiHtDF+kgcAms/m8+ZgMdDZAKwCeBut8awHIlK7SGKEcmkE5S5ea k+rmwWh7asJsBn3oG31CVG3BSH17g3uTWGjRXc1KX/hFRfFMV7Hfgk4qQyBl+djMsmcn BIlbB7Q0hCC8oZqj9o+2U/C8VjrUH/y+po55siTSnnKIzA3AenNl8jkAfpVPr+ZAg0Jh lbwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774335953; x=1774940753; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=eJqRw8wJksOuCmbVXg0UKSzuvntxhtDkZlZiq7BcWIo=; b=ZzIbgNFT7uln1dGbF256fT1gK4gKbm2gJfR71D809yKU4sM0Pkctp3h+RBhlvTpX0F Gnp2F8C1Nevkb9fArTHXYH2dI3Adi57oVZ128Arc8KWONWhzBgXhjxccUB3mDlsj3Yfw TrJCzd9lYH4w+JnopD5d9J9xHH+6gavkv8vDpPByvzNNTo9RUAu8PlohrxAgHqAsVMWA seqqoJ30IpfsWgywBlNfJzIVzMvJ2QhEXCDKkg42lpNnye7yhd5b2NIis15RQP1vicIz PCzFe/8vFHxBzmcEZMfQRSEvRYRWS2t71CzLwSygomxdU7yWZBbGOPlAWjluUb2TGj5b yWNQ== X-Forwarded-Encrypted: i=1; AJvYcCUacOYlNbIC41F7yh9lZxBE6xNDTUuZ5b6eSlgt9Fre0GGffrcVwVK7igFKgj/t91uGyBeiLRDPCiNoyuo=@vger.kernel.org X-Gm-Message-State: AOJu0YyKSJwHrhrgsMcAJa9v2aKQbX51SNrKDeVJQJh2a0qRmmOtBwbw Np5wGREO7H7v9d8gpaC0eHd+y0A5/8C9ys2UDM7yZXXED41ZtgVYmL4RrwfIy4WXdNU= X-Gm-Gg: ATEYQzzYgyfNWshnzXhOGRFJcrvwaLhzeuiiW4XOZeVDMBMUEd8DO4ZLNIbKUhuF5dd NzG7V2gT940buM8iIC6dceZjsiMUJWCsyPXnoJOwvXltnfMS9SJeKx6cU2Rl6ONXYoafPbyCV/T P5VLEr0SGxDeDFeM68Msjdy84I/SwPHarojoG44ft/4sU9QX/GEDAqYgFnxiZANEYrOWmcsnx7g l+T8I5GLOw9YsACZZDNtgdyokK9Dm0gvKecragPFy/tv3f4034Bkzympi5eAbmi7MmoUSWoQCT0 KtsJYTthawJF0k6Li7LJ46vQz6Y5dt8tlXU3PpxMsFOrR6aQ3R/DqxQZBS/7zF8D5ol8vYLBJZV Yx7eDZ0AKkMkqHcU3i0TRz2RfHVDiYr3zDmfuOKVdbuWB/EANiNeTqwm64F1pNAsXlELSX1Kcln AcYRRlVv1phu5w7alGFecQquPAALHf X-Received: by 2002:a05:600c:3549:b0:485:3fe6:21f5 with SMTP id 5b1f17b1804b1-486fedb5928mr200915295e9.10.1774335952742; Tue, 24 Mar 2026 00:05:52 -0700 (PDT) Received: from localhost ([196.207.164.177]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48711022f37sm18358185e9.9.2026.03.24.00.05.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Mar 2026 00:05:52 -0700 (PDT) Date: Tue, 24 Mar 2026 10:05:49 +0300 From: Dan Carpenter To: Keith Busch Cc: Sungwoo Kim , Jens Axboe , Christoph Hellwig , Sagi Grimberg , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Harshit Mogalapalli Subject: Re: [PATCH] nvme: remove bogus check in nvme_pr_read_keys() Message-ID: References: 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, Mar 23, 2026 at 11:53:23AM -0600, Keith Busch wrote: > On Sat, Mar 21, 2026 at 01:26:25PM +0300, Dan Carpenter wrote: > > This check for if (rse_len > U32_MAX) is confusing because if > > rse_len is > INT_MAX, that will trigger a WARN() in kvzalloc(). > > Fortunately, the caller blkdev_pr_read_keys(), puts a limit on num_keys. > > The number of keys can't be more than PR_KEYS_MAX (65536) and the > > condition is impossible. > > There's actually two callers: blkdev_pr_read_keys() ensures the number of > keys is smaller than 65536 and iblock_pr_read_keys() is a fixed size at > 16. But begs the question, what guarantee does nvme_pr_read_keys() have > that all the callers validated the number of keys such that it can > bravely skip checking it? We normally wouldn't check the return from struct_size(). We would just pass it to the allocation function and let the failure happen since nothing can allocate SIZE_MAX. Linus added the INT_MAX check in kvzalloc() because it used to allocate more but we capped it at INT_MAX to avoid a problem where sometimes people store sizes int a u32. vmalloc() can still allocate larger sizes than that if you really need to. Linus has since suggested that the WARN() could be removed if people want to since hopefully all the people who were using kvmalloc() to allocate more than 2GB have changed to vmalloc() now. So far no one has done that. > I think nvme should validate that it's a > reasonable value before calling kvalloc so we return an apporpriate > EINVAL instead of ENOMEM. The existing UINT_MAX check is certainly far > too high, but I think something like a 4MB payload would be a totally > reasonable upper limit for nvme on this function. That also works. regards, dan carpenter