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

[Yuehong Wu]

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.