Re: [PATCH v3] nvme-auth: Don't propose NVME_AUTH_DHGROUP_NULL with SC_C

[Alistair Francis]

On Thu, Mar 19, 2026 at 2:25 AM Chris Leech <cleech@xxxxxxxxxx> wrote:
>
> On Wed, Mar 18, 2026 at 08:56:55AM +0100, Christoph Hellwig wrote:
> > On Wed, Mar 18, 2026 at 10:46:58AM +1000, alistair23@xxxxxxxxx wrote:
> > >
> > > +#define DH_GID_LIST_OFFSET 30
> >
> > Note that we have a target side patch ("nvmet: auth: validate dhchap id
> > list lengths") also adding defines related to this, but in a different
> > place and using different naming:
> >
> >
> > +#define NVME_AUTH_DHCHAP_MAX_HASH_IDS 30
> > +#define NVME_AUTH_DHCHAP_MAX_DH_IDS 30
> >
> > Back in the day we usually did nvme.h patch separately to handle these
> > kinds of conflicts a little better.
> >
> > YunJe/Alistair, maybe whoever resends next should split this out,
> > add all the required values and add a pointer to the spec?
>
> Is there a good reason to keep a single idlist[60] in the struct
> defintiion and need this offset at all? Or can we repalce it with
> somthing like haidlist[30], dhidlist[30]?
>
> NVMe base spec r2.3 section is 8.3.5.5.2, where these are seperate
> fields named HashIDList and DHgIDList.

The 2.1 spec kind of implies a single array with an offset of 33 for
the DHgIDList, which I assume is why this was written the way it is.

I'm open to changing it if people free strongly though

Alistair

>
> - Chris
>