Re: [PATCH] nvme: fix memory allocator in nvme_pr_read_keys()

[Sungwoo Kim]

On Mon, Feb 23, 2026 at 8:41 AM Christoph Hellwig <hch@xxxxxx> wrote:
>
> s/allocator/allocation/ in the subject.
>
> > -     rse = kzalloc(rse_len, GFP_KERNEL);
> > +     rse = kvzalloc(rse_len, GFP_KERNEL);
>
> You'll also need it to free it using kvfree if you you use kvzalloc.

Will do in V2. Thanks for your review.

> We might also want to add some upper bound to the number of keys
> to not allow the user to allocate 4GB of pinned kernel memory.

Could this be a typo for 4MB? Users cannot request 4GB, since it already
has an upper bound, PR_KEYS_MAX (64K). The maximum requested memory
size is 4MB + 64 bytes as follows:

// struct_size(rse, regctl_eds, num_keys)
64K * 64 + 64 = 4M + 64 bytes.

We might still want to know that 4MB is okay. I think it is fine, but
we can shrink it as
the current upper bound is more than sufficient, according to the
relevant conversation:

>How about limiting num_keys to 64K (1u << 16)? In practice, PR keys
>are used for shared storage coordination and typical deployments have
>only a handful of hosts, so this should be more than enough for any
>realistic use case.
https://lore.kernel.org/linux-block/CADhLXY57aFmNB1v4TG2YxhOQL1+_02KkWpB3fEsn8t1GiFqdrg@xxxxxxxxxxxxxx/

On Mon, Feb 23, 2026 at 8:41 AM Christoph Hellwig <hch@xxxxxx> wrote:
>
> s/allocator/allocation/ in the subject.
>
> > -     rse = kzalloc(rse_len, GFP_KERNEL);
> > +     rse = kvzalloc(rse_len, GFP_KERNEL);
>
> You'll also need it to free it using kvfree if you you use kvzalloc.
>
> We might also want to add some upper bound to the number of keys
> to not allow the user to allocate 4GB of pinned kernel memory.
>
>