From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@kernel.org>
Cc: Dan Carpenter <dan.carpenter@linaro.org>,
Sungwoo Kim <iam@sung-woo.kim>, Jens Axboe <axboe@kernel.dk>,
Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Subject: Re: [PATCH] nvme: remove bogus check in nvme_pr_read_keys()
Date: Tue, 24 Mar 2026 07:53:08 +0100 [thread overview]
Message-ID: <20260324065308.GA1578@lst.de> (raw)
In-Reply-To: <acF-E8csusg-YbaO@kbusch-mbp>
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? 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.
Agreed.
next prev parent reply other threads:[~2026-03-24 6:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-21 10:26 [PATCH] nvme: remove bogus check in nvme_pr_read_keys() Dan Carpenter
2026-03-23 17:53 ` Keith Busch
2026-03-24 6:53 ` Christoph Hellwig [this message]
2026-03-24 7:05 ` Dan Carpenter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260324065308.GA1578@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=dan.carpenter@linaro.org \
--cc=harshit.m.mogalapalli@oracle.com \
--cc=iam@sung-woo.kim \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.