[PATCH] nvmet: clamp the last ANA group index against the real array size

[Andrew Stellman]

Thanks, Yuehong. I’ve sent a v2 of my original that answers Sagi’s
question and links to your testing:
https://lore.kernel.org/r/20261106134313.34829-1-astellman@stellman-greene.com



On Fri, Nov 6, 2026 at 2:04 AM Yuehong Wu
<wuyuehong at cmss.chinamobile.com> wrote:
>
> I missed that this was already reported: Andrew posted the same two-line
> change on 2026-09-10
>
>   https://lore.kernel.org/linux-nvme/20260910154849.66095-1-astellman@stellman-greene.com/
>
> and Sagi asked in that thread whether it had been tested.  That patch
> reasons the same way, and it also cites the spec wording for a valid ANA
> group identifier (non-zero and <= ANAGRPMAX), which mine should have
> quoted as well.
>
> What I can add is the evidence that was asked for.  On
> 7.3.0-next-20261027, with two kernels built from the same tree that
> differ only in these two lines and no instrumentation, the nvme-loop
> transport shows: a group created as ports/1/ana_groups/128 is
> absent from the ANA log page before the patch (ngrps=1) and present
> after it (ngrps=2); 128 written to a namespace ana_grpid reads back as 0
> before the patch and as 128 after it, with the namespace accounted to
> group 128; and removing the group again adds a phantom group 128 (state
> inaccessible, 0 namespaces) to the ANA log page only in the unpatched
> kernel.  The exact steps are in the --- section of my patch.
>
> Andrew's patch is against a September tree and no longer applies, which
> is why I sent a rebased version.  If you would rather take his original,
> I have no objection.
>
>
>