[PATCH] nvme: make providing NGUID as UUID usage less scary

[PATCH] nvme: make providing NGUID as UUID usage less scary

[AlanCui4080]

Hi, 

> From: Keith Busch <kbusch@kernel.org>
> 
> The warning is a bit alarming, and it only prints for the very first
> non-sgl capable device that receives a passthrough command. Just log an
> informational message on initial discovery for every device.

Since we decide to show this warning at device initial discovery stage,
here are some similar warnings that I think are essentially the same.

grep -C3 -rn "dev_warn_once" ./drivers/nvme/*
```
./drivers/nvme/host/sysfs.c-147-         * we have no UUID set
./drivers/nvme/host/sysfs.c-148-         */
./drivers/nvme/host/sysfs.c-149-        if (uuid_is_null(&ids->uuid)) {
./drivers/nvme/host/sysfs.c:150:                dev_warn_once(dev,
./drivers/nvme/host/sysfs.c-151-                        "No UUID available providing old NGUID\n");
./drivers/nvme/host/sysfs.c-152-                return sysfs_emit(buf, "%pU\n", ids->nguid);
./drivers/nvme/host/sysfs.c-153-        }
```

This warning will only complain for the first partition of the first device also.
And for NVMe devices, according to the NVM-Express-1_4 specification p.175 Figure 251:
"Bit 9 (UUID List): ...", UUID is not mandatory i guess. So let's degrade it into a
informational message on initial discovery for every device.

Signed-off-by: Alan Cui <me@alancui.cc>
---
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 3fdcd73b9546..c432d8bc7b62 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -4296,6 +4296,10 @@ static void nvme_validate_ns(struct nvme_ns *ns, struct nvme_ns_info *info)
                goto out;
        }
 
+       if (uuid_is_null(&info->ids.uuid)) {
+               dev_info(ns->ctrl->device, "No UUID available, uuid_show providing old NGUID\n");
+       }
+
        ret = nvme_update_ns_info(ns, info);
 out:
        /*
diff --git a/drivers/nvme/host/sysfs.c b/drivers/nvme/host/sysfs.c
index 29430949ce2f..839a36c22ebf 100644
--- a/drivers/nvme/host/sysfs.c
+++ b/drivers/nvme/host/sysfs.c
@@ -147,8 +147,6 @@ static ssize_t uuid_show(struct device *dev, struct device_attribute *attr,
         * we have no UUID set
         */
        if (uuid_is_null(&ids->uuid)) {
-               dev_warn_once(dev,
-                       "No UUID available providing old NGUID\n");
                return sysfs_emit(buf, "%pU\n", ids->nguid);
        }
        return sysfs_emit(buf, "%pU\n", &ids->uuid);

--
2.54.0

[PATCH V2] nvme: make providing NGUID as UUID usage less scary

[AlanCui4080]

Since we decide to show the prp passthrough usage warning at device
initial discovery stage and degrade it to a informational message,
here is a warning that I think are essentially the same.

grep -C3 -rn "dev_warn_once" ./drivers/nvme/*
```
./drivers/nvme/host/sysfs.c-147-         * we have no UUID set
./drivers/nvme/host/sysfs.c-148-         */
./drivers/nvme/host/sysfs.c-149-        if (uuid_is_null(&ids->uuid)) {
./drivers/nvme/host/sysfs.c:150:                dev_warn_once(dev,
./drivers/nvme/host/sysfs.c-151-                        "No UUID available providing old NGUID\n");
./drivers/nvme/host/sysfs.c-152-                return sysfs_emit(buf, "%pU\n", ids->nguid);
./drivers/nvme/host/sysfs.c-153-        }
```

This warning will only complain for the first partition of the first device also.
And for NVMe devices, according to the NVM-Express-1_4 specification p.175 Figure 251:
"Bit 9 (UUID List): ...", UUID is not mandatory. So let's degrade it into a
informational message on initial discovery for every device.

Signed-off-by: Alan Cui <me@alancui.cc>
---
v2: move the hint to nvme_init_ns_head instead of nvme_validate_ns
v2: clean the commit message lines

In my understanding, the nvme_init_ns_head will be called each time
a namespace created, and it does some checking on ids so we also place
the hint there, and here is the result of dmesg applied current patch.

[    4.502052] nvme nvme1: pci function 0000:05:00.0
[    4.502060] nvme nvme0: pci function 0000:01:00.0
[    4.508544] nvme nvme1: missing or invalid SUBNQN field.
[    4.508664] nvme nvme1: D3 entry latency set to 8 seconds
[    4.512422] nvme nvme0: missing or invalid SUBNQN field.
[    4.517581] nvme nvme0: allocated 32 MiB host memory buffer (1 segment).
[    4.523519] nvme nvme0: 8/0/0 default/read/poll queues
[    4.524761] nvme nvme1: 16/0/0 default/read/poll queues
[    4.525438] nvme nvme0: No UUID available, uuid_show providing old NGUID
[    4.526683] nvme nvme1: No UUID available, uuid_show providing old NGUID
[    4.527243]  nvme0n1: p1 p2 p3 p4 p5 p6
[    4.528351]  nvme1n1: p1

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 766e9cc4ffca..70856856a99c 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -4007,6 +4007,10 @@ static int nvme_init_ns_head(struct nvme_ns *ns, struct nvme_ns_info *info)
 		ctrl->quirks |= NVME_QUIRK_BOGUS_NID;
 	}
 
+	if (uuid_is_null(&info->ids.uuid)) {
+		dev_info(ctrl->device, "No UUID available, uuid_show providing old NGUID\n");
+	}
+
 	mutex_lock(&ctrl->subsys->lock);
 	head = nvme_find_ns_head(ctrl, info->nsid);
 	if (!head) {
diff --git a/drivers/nvme/host/sysfs.c b/drivers/nvme/host/sysfs.c
index 16c6fea4b2db..ea8bce9887f9 100644
--- a/drivers/nvme/host/sysfs.c
+++ b/drivers/nvme/host/sysfs.c
@@ -147,8 +147,6 @@ static ssize_t uuid_show(struct device *dev, struct device_attribute *attr,
 	 * we have no UUID set
 	 */
 	if (uuid_is_null(&ids->uuid)) {
-		dev_warn_once(dev,
-			"No UUID available providing old NGUID\n");
 		return sysfs_emit(buf, "%pU\n", ids->nguid);
 	}
 	return sysfs_emit(buf, "%pU\n", &ids->uuid);
--
2.54.0

Re: [PATCH] nvme: make providing NGUID as UUID usage less scary

[Sagi Grimberg]

On 07/05/2026 19:36, AlanCui4080 wrote:
> Hi,
>
>> From: Keith Busch <kbusch@kernel.org>
>>
>> The warning is a bit alarming, and it only prints for the very first
>> non-sgl capable device that receives a passthrough command. Just log an
>> informational message on initial discovery for every device.
> Since we decide to show this warning at device initial discovery stage,
> here are some similar warnings that I think are essentially the same.
>
> grep -C3 -rn "dev_warn_once" ./drivers/nvme/*
> ```
> ./drivers/nvme/host/sysfs.c-147-         * we have no UUID set
> ./drivers/nvme/host/sysfs.c-148-         */
> ./drivers/nvme/host/sysfs.c-149-        if (uuid_is_null(&ids->uuid)) {
> ./drivers/nvme/host/sysfs.c:150:                dev_warn_once(dev,
> ./drivers/nvme/host/sysfs.c-151-                        "No UUID available providing old NGUID\n");
> ./drivers/nvme/host/sysfs.c-152-                return sysfs_emit(buf, "%pU\n", ids->nguid);
> ./drivers/nvme/host/sysfs.c-153-        }
> ```
>
> This warning will only complain for the first partition of the first device also.
> And for NVMe devices, according to the NVM-Express-1_4 specification p.175 Figure 251:
> "Bit 9 (UUID List): ...", UUID is not mandatory i guess. So let's degrade it into a
> informational message on initial discovery for every device.
>
> Signed-off-by: Alan Cui <me@alancui.cc>
> ---
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index 3fdcd73b9546..c432d8bc7b62 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -4296,6 +4296,10 @@ static void nvme_validate_ns(struct nvme_ns *ns, struct nvme_ns_info *info)
>                  goto out;
>          }
>   
> +       if (uuid_is_null(&info->ids.uuid)) {
> +               dev_info(ns->ctrl->device, "No UUID available, uuid_show providing old NGUID\n");
> +       }
> +
>          ret = nvme_update_ns_info(ns, info);
>   out:
>          /*
> diff --git a/drivers/nvme/host/sysfs.c b/drivers/nvme/host/sysfs.c
> index 29430949ce2f..839a36c22ebf 100644
> --- a/drivers/nvme/host/sysfs.c
> +++ b/drivers/nvme/host/sysfs.c
> @@ -147,8 +147,6 @@ static ssize_t uuid_show(struct device *dev, struct device_attribute *attr,
>           * we have no UUID set
>           */
>          if (uuid_is_null(&ids->uuid)) {
> -               dev_warn_once(dev,
> -                       "No UUID available providing old NGUID\n");
>                  return sysfs_emit(buf, "%pU\n", ids->nguid);
>          }
>          return sysfs_emit(buf, "%pU\n", &ids->uuid);

TBH, I'm not sure why should this be a warning or an info log. This 
looks like a debug print to me.

Keith WDYT?

Re: [PATCH] nvme: make providing NGUID as UUID usage less scary

[AlanCui4080]

Hi,

On Monday, 11 May 2026 06:19，you wrote：

> TBH, I'm not sure why should this be a warning or an info log. This 
> looks like a debug print to me.
> 
> Keith WDYT?

By the way, current way how kernel generate UUID by NGUID is
not compliant with RFC 4122 and NVMe spec.

[alan@AlanArchDesktop ~]$ cat /sys/block/nvme0n1/uuid 
00000000-0000-0000-a428-xxxxxxxxxxxx
[alan@AlanArchDesktop ~]$ cat /sys/block/nvme0n1/nguid 
00000000-0000-0000-a428-xxxxxxxxxxxx

And according to NVMe 1.4 spec 7.10.6 UUID
   The Universally Unique Identifier is defined in RFC4122 and con-
   tained in the Namespace Identification Descriptor

So,
According to RFC 4122 4.3 Algorithm for Creating a Name-Based UUID:

> The version 3 or 5 UUID is meant for generating UUIDs from "names"
> that are drawn from, and unique within, some "name space".  The
> concept of name and name space should be broadly construed, and not
> limited to textual names.  For example, some name spaces are the
> domain name system, URLs, ISO Object IDs (OIDs), X.500 Distinguished
> Names (DNs), and reserved words in a programming language.  The
> mechanisms or conventions used for allocating names and ensuring
> their uniqueness within their name spaces are beyond the scope of
> this specification.
...
> The algorithm for generating a UUID from a name and a name space are
> as follows:
>  o  Allocate a UUID to use as a "name space ID" for all UUIDs
>     generated from names in that name space; see Appendix C for some
>     pre-defined values.
>  o  Choose either MD5 [4] or SHA-1 [8] as the hash algorithm; If
>     backward compatibility is not an issue, SHA-1 is preferred.
>  o  Convert the name to a canonical sequence of octets (as defined by
>     the standards or conventions of its name space); put the name
>     space ID in network byte order.
>  o  Compute the hash of the name space ID concatenated with the name.
>  o  Set octts zero through 3 of the time_low field to octets zero
>     through 3 of the hash.
>  o  Set octets zero and one of the time_mid field to octets 4 and 5 of
>     the hash.
>  o  Set octets zero and one of the time_hi_and_version field to octets
>     6 and 7 of the hash.
>  o  Set the four most significant bits (bits 12 through 15) of the
>     time_hi_and_version field to the appropriate 4-bit version number
>     from Section 4.1.3.
>  o  Set the clock_seq_hi_and_reserved field to octet 8 of the hash.
>  o  Set the two most significant bits (bits 6 and 7) of the
>     clock_seq_hi_and_reserved to zero and one, respectively.
>  o  Set the clock_seq_low field to octet 9 of the hash.
>  o  Set octets zero through five of the node field to octets 10
>     through 15 of the hash.
>  o  Convert the resulting UUID to local byte order.

However, the NVMe spec does not specified a namespace ID, so,
I selected a stirng "nqn.2014-08.org.nvmexpress:nguid",
then do SHA1 on it, get 4dead072-6b40-f992-9447-40f235d55fee,
then replace the version to '5' and variant to '1' to follow RFC 4122, get 4dead072-6b40-1992-8447-40f235d55fee

So for the NGUID A42812345678ABCD, a way to generate a canonnical
UUID is:
```
import uuid
namespace = uuid.UUID('4dead072-6b40-1992-8447-40f235d55fee')
nguid_bytes = bytes.fromhex('A42812345678ABCD')
result_uuid = uuid.uuid5(namespace, nguid_bytes)
print(result_uuid)
```
Resulting 9f4344db-6bf0-5782-b8a9-a08b6aa55169.

It's too complicated, right? RFC9562 provides us UUIDv8, 

> UUIDv8 provides a format for experimental or vendor-specific
>  use cases. The only requirement is that the variant and version
>  bits MUST be set as defined in Sections 4.1 and 4.2.

Let's set the first 6 avalible custom bytes to "NGUID:",
move the first 4bits of NGUID before the variant 4bits .

So for the NGUID A42812345678ABCD, it's 78718573-6858-800A-8428-12345678abcd.

Alan.

Re: [PATCH] nvme: make providing NGUID as UUID usage less scary

[Christoph Hellwig]

[the patch seem to be missing some maintainer Ccs]

On Mon, May 11, 2026 at 01:19:59AM +0300, Sagi Grimberg wrote:
> TBH, I'm not sure why should this be a warning or an info log. This looks
> like a debug print to me.

It is worse.  For some reason the commit seems to imply the uuid
replaces the nguid and they can be intermixed.

We really need separate sysfs files for the different ids.  I gues we
need to keep the existing one someone, but it is a mess.

[PATCH RFC V2 RESEND] nvme: make providing NGUID as UUID usage less scary

[AlanCui4080]

Since we decide to show the prp passthrough usage warning at device
initial discovery stage and degrade it to a informational message,
here is a warning that I think are essentially the same.

grep -C3 -rn "dev_warn_once" ./drivers/nvme/*
```
./drivers/nvme/host/sysfs.c-147-         * we have no UUID set
./drivers/nvme/host/sysfs.c-148-         */
./drivers/nvme/host/sysfs.c-149-        if (uuid_is_null(&ids->uuid)) {
./drivers/nvme/host/sysfs.c:150:                dev_warn_once(dev,
./drivers/nvme/host/sysfs.c-151-                        "No UUID available providing old NGUID\n");
./drivers/nvme/host/sysfs.c-152-                return sysfs_emit(buf, "%pU\n", ids->nguid);
./drivers/nvme/host/sysfs.c-153-        }
```

This warning will only complain for the first partition of the first device also.
And for NVMe devices, according to the NVM-Express-1_4 specification p.175 Figure 251:
"Bit 9 (UUID List): ...", UUID is not mandatory. So let's degrade it into a
informational message on initial discovery for every device.

Signed-off-by: Alan Cui <me@alancui.cc>
---
v2: move the hint to nvme_init_ns_head instead of nvme_validate_ns
v2: clean the commit message lines

In my understanding, the nvme_init_ns_head will be called each time
a namespace created, and it does some checking on ids so we also place
the hint there, and here is the result of dmesg applied current patch.

resend v2: add Ccs to all maintainers
resend v2: see https://lists.infradead.org/pipermail/linux-nvme/2026-May/062831.html

After discussion, I begin to think we should treat this as a warning,
since the way kernel generate UUID by NGUID is not a valid RFC4122 UUID,
and NVMe specification requires "The Universally Unique Identifier is defined in RFC4122"

However the "No UUID available providing old NGUID" is should be reported
per device anyway.

[    4.502052] nvme nvme1: pci function 0000:05:00.0
[    4.502060] nvme nvme0: pci function 0000:01:00.0
[    4.508544] nvme nvme1: missing or invalid SUBNQN field.
[    4.508664] nvme nvme1: D3 entry latency set to 8 seconds
[    4.512422] nvme nvme0: missing or invalid SUBNQN field.
[    4.517581] nvme nvme0: allocated 32 MiB host memory buffer (1 segment).
[    4.523519] nvme nvme0: 8/0/0 default/read/poll queues
[    4.524761] nvme nvme1: 16/0/0 default/read/poll queues
[    4.525438] nvme nvme0: No UUID available, uuid_show providing old NGUID
[    4.526683] nvme nvme1: No UUID available, uuid_show providing old NGUID
[    4.527243]  nvme0n1: p1 p2 p3 p4 p5 p6
[    4.528351]  nvme1n1: p1

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 766e9cc4ffca..70856856a99c 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -4007,6 +4007,10 @@ static int nvme_init_ns_head(struct nvme_ns *ns, struct nvme_ns_info *info)
 		ctrl->quirks |= NVME_QUIRK_BOGUS_NID;
 	}
 
+	if (uuid_is_null(&info->ids.uuid)) {
+		dev_info(ctrl->device, "No UUID available, uuid_show providing old NGUID\n");
+	}
+
 	mutex_lock(&ctrl->subsys->lock);
 	head = nvme_find_ns_head(ctrl, info->nsid);
 	if (!head) {
diff --git a/drivers/nvme/host/sysfs.c b/drivers/nvme/host/sysfs.c
index 16c6fea4b2db..ea8bce9887f9 100644
--- a/drivers/nvme/host/sysfs.c
+++ b/drivers/nvme/host/sysfs.c
@@ -147,8 +147,6 @@ static ssize_t uuid_show(struct device *dev, struct device_attribute *attr,
 	 * we have no UUID set
 	 */
 	if (uuid_is_null(&ids->uuid)) {
-		dev_warn_once(dev,
-			"No UUID available providing old NGUID\n");
 		return sysfs_emit(buf, "%pU\n", ids->nguid);
 	}
 	return sysfs_emit(buf, "%pU\n", &ids->uuid);
--
2.54.0

Re: [PATCH] nvme: make providing NGUID as UUID usage less scary

[AlanCui4080]

On Monday, 11 May 2026 16:16，Christoph Hellwig wrote：
> [the patch seem to be missing some maintainer Ccs]

Sorry, I've resent it.

> On Mon, May 11, 2026 at 01:19:59AM +0300, Sagi Grimberg wrote:
> > TBH, I'm not sure why should this be a warning or an info log. This looks
> > like a debug print to me.
> 
> It is worse.  For some reason the commit seems to imply the uuid
> replaces the nguid and they can be intermixed.

Which you refer to?

If it's my patch, My patch is actually intended to fix the issue where
"the kernel uses dev_warn_once, thus only reporting warnings for the
first block or drive where this problem occurs". So the key is "This
asymmetry can be misleading to users. If all devices in the system report 
the same issue, it might not be a problem, but if only one device reports it, 
it might (especially since I have two identical drives). ".

Futher more, should it be reported as a warning? The answer is No:
According to the NVM-Express-1_4 specification p.175 Figure 251:
"Bit 9 (UUID List): ...", UUID is not mandatory. And for devices below
spec revision 1.3, there is no UUID yet.

And yes?? Because according to NVMe 1.4 spec 7.10.6 UUID:
> The Universally Unique Identifier is defined in RFC4122 and con-
> tained in the Namespace Identification Descriptor
Current way how kernel generate UUID by NGUID is not compliant with RFC 4122
and NVMe spec. 
[alan@AlanArchDesktop ~]$ cat /sys/block/nvme0n1/uuid 
00000000-0000-0000-a428-xxxxxxxxxxxx
[alan@AlanArchDesktop ~]$ cat /sys/block/nvme0n1/nguid 
00000000-0000-0000-a428-xxxxxxxxxxxx

> We really need separate sysfs files for the different ids.  I gues we
> need to keep the existing one someone, but it is a mess.

I don't really know how and why user needs this UUID, because kernel said:

/* For backward compatibility expose the NGUID to userspace if
 * we have no UUID set
 */ 

[alan@AlanArchDesktop ~]$ ls /sys/block/nvme0n1/uuid (NVMe 1.4)
/sys/block/nvme0n1/uuid
[alan@AlanArchDesktop ~]$ cat /sys/block/nvme0n1/uuid 
00000000-0000-0000-a428-xxxxxxxxxxxx
[alan@AlanArchDesktop ~]$ cat /sys/block/nvme0n1/nguid 
00000000-0000-0000-a428-xxxxxxxxxxxx
[alan@AlanArchDesktop ~]$ ls /sys/block/nvme2n1/uuid (NVMe 1.3)
ls: cannot access '/sys/block/nvme2n1/uuid': No such file or directory
[alan@AlanArchDesktop ~]$ cat /sys/block/nvme2n1/nguid 
cat: /sys/block/nvme2n1/nguid: No such file or directory
[alan@AlanArchDesktop ~]$ cat /sys/block/nvme2n1/uuid 
cat: /sys/block/nvme2n1/uuid: No such file or directory

If it's mandatory for userspace, why the nvme2n1 has not, if it's not
mandatory, why should we create the UUID sysfd attr. then put NGUID in it?
But for a NVMe 1.3 device there is both no UUID and no NGUID, while kernel
is not reporting warnings at all?

The NVMe 1.4 spec Figure. 253 said:
> If the namespace does not support an IEEE Extended Unigue ldentifier
> (i.e., EUI64 field is cleared to 0h) and does not support a Namespace
> Globally Unigue ldentifier (i.e., the NGUID field is cleared to Oh), then
> the namespace shall report a Namespace ldentification Descriptor with
> a value of type 3h.

So it's really a optional parameter right?

Alan

Re: [PATCH] nvme: make providing NGUID as UUID usage less scary

[AlanCui4080]

On Monday, 11 May 2026 16:59，I wrote:
> For NVMe spec revision 1.3, there is no UUID yet.
> 

> If it's mandatory for userspace, why the nvme2n1 has not, if it's not
> mandatory, why should we create the UUID sysfd attr. then put NGUID in it?
> But for a NVMe 1.3 device there is both no UUID and no NGUID, while kernel
> is not reporting warnings at all?

Sorry, I checked the 1.3 specification and found that there is
NGUID and UUID in it.

The only difference between revision 1.3 and 1.4 is Revision 1.4
states that UUIDs should be reported when neither EUI64 nor NGUID is supported.

It seems that for an NVMe 1.4 device, its UUID is mandatory when EUI64/NGUID
is not supported. However, the kernel chooses to expose both the UUID and
NGUID of a device with an NGUID but no UUID to sysfs, then warns us every
time we read the device that an NGUID is being used to impersonate a UUID.

But for an NVMe 1.3 device, its UUID is optional when EUI64/NGUID is not
present. However, the kernel chooses not to expose either the UUID or NGUID
of a device with an NGUID but no UUID to sysfs.

This is incredibly strange.

Alan.

Re: [PATCH RFC V2 RESEND] nvme: make providing NGUID as UUID usage less scary

[AlanCui4080]

[see https://lists.infradead.org/pipermail/linux-nvme/2026-May/062762.html for full thread]

Hi everyone,

About this patch and the discussion above, I just did a survey on
kernel commit history:

Long ago, the kernel sees NGUID as UUID.

2b9b6e86bca7209de02754fc84acf7ab3e78734e (NVMe: Export namespace attributes to sysfs)
> 	if (ns->ctrl->vs >= NVME_VS(1, 2))
>		memcpy(ns->uuid, id->nguid, sizeof(ns->uuid));

Then, the kernel begins by retrieving the UUID from the driver and,
in a backward compatible manner, reports the NGUID as the UUID when
the UUID is unavailable, and throws a warning.

d934f9848a77be4afe0ca336ea419dd066c934f3 (nvme: provide UUID value to userspace
Now that we have a way for getting the UUID from a target, provide it
to userspace as well.
Unfortunately there is already a sysfs attribute called UUID which is
a misnomer as it holds the NGUID value. So instead of creating yet
another wrong name, create a new 'nguid' sysfs attribute for the
NGUID. For the UUID attribute add a check wheter the namespace has a
UUID assigned to it and return this or return the NGUID to maintain
backwards compatibility. This should give userspace a chance to catch
up.)
>    static ssize_t uuid_show(...)
>	/* For backward compatibility expose the NGUID to userspace if
>	 * we have no UUID set
>	 */
>	if (uuid_is_null(&ns->uuid)) {
>		printk_ratelimited(KERN_WARNING
>				   "No UUID available providing old NGUID\n");
>		return sprintf(buf, "%pU\n", ns->nguid);
>	}
>	return sprintf(buf, "%pU\n", &ns->uuid);

And at d934f984:

> static umode_t nvme_ns_attrs_are_visible(struct kobject *kobj,
>		struct attribute *a, int n)
>{
>	struct device *dev = container_of(kobj, struct device, kobj);
>	struct nvme_ns *ns = nvme_get_ns_from_dev(dev);
>
>	if (a == &dev_attr_uuid.attr) {
>		if (uuid_is_null(&ns->uuid) ||
>		    !memchr_inv(ns->nguid, 0, sizeof(ns->nguid))) // ??????? Why
>			return 0;
>	}
>	if (a == &dev_attr_nguid.attr) {
>		if (!memchr_inv(ns->nguid, 0, sizeof(ns->nguid)))
>			return 0;
>	}
>	if (a == &dev_attr_eui.attr) {
>		if (!memchr_inv(ns->eui, 0, sizeof(ns->eui)))
>			return 0;
>	}Therefore, my suggestion is to directly remove the UUID that is copied from NGUID.
>	return a->mode;
>}

The visibility of the uuid attr is depends on if NGUID exists, I'dont know why.
I believe that in this scenario, if NGUID doesn't exist, then UUID won't exist either.
Therefore, the user-space assumption that UUID exists has always been a bug.
Consequently, we don't need to assume any responsibility for backward compatibility.

I have hard drives that can demonstrate this behavior.

```
sudo nvme id-ctrl /dev/nvme1n1
vid       : 0x144d
mn        : Samsung SSD 970 EVO Plus 500GB          
fr        : 2B2QEXM7
ieee      : 002538
ver       : 0x10300

cat /sys/block/nvme1n1/eui
00 25 ** ** ** ** ** 2a

cat /sys/block/nvme1n1/nguid
cat: /sys/block/nvme1n1/nguid: No such file or directory

cat /sys/block/nvme1n1/uuid
cat: /sys/block/nvme1n1/uuid: No such file or directory

cat /sys/block/nvme1n1/wwid
eui.0025**********a2
```
As you can see, this NVMe 1.3 compatible device have no nguid,
so it has no both nguid and uuid node.

```
sudo nvme id-ctrl /dev/nvme0n1
NVME Identify Controller:
vid       : 0x1e49
mn        : ZHITAI TiPlus7100 2TB                   
fr        : ZTA22002
ieee      : 000000
ver       : 0x10400

cat /sys/block/nvme0n1/eui
a4 ** ** ** ** ** ** c3

cat /sys/block/nvme0n1/nguid
00000000-0000-0000-a428-**********c3

cat /sys/block/nvme0n1/uuid
00000000-0000-0000-a428-**********c3

cat /sys/block/nvme0n1/wwid
eui.0000000000000000a428**********c3
```
As you can see, this NVMe 1.4 compatible device have a nguid, its nguid
is derived from eui64, then because it has an nguid, its uuid is visible
and is copied from nguid.

According to the spec., both devices are compliant.

Therefore, I believe the core issue is no longer just the level or location
of the warning. As you can see, in the current version of the kernel,
the visibility of each attr is highly device-dependent. I think we shouldn't
retain a backward-compatible UUID attr since no userspace software should
assume the existence of any attr and The current kernel code is not backward
compatible in essence! (How can userspace determine whether a device has an
NGUID through means other than the kernel sysfs? If a program in a previous
version assumed the existence of /sys/block/nvmexx/uuid, then that assumption
is incorrect, because NGUID itself may not exist. Only any one of EUI, NGUID,
and UUID needs to exist.)

Another issue is Why WWIDs generated from NGUIDs have prefix "eui."?
Seems come from:
118472ab8532e55f48395ef5764b354fe48b1d73 (NVMe: Expose ns wwid through single sysfs entry)
> if (memchr_inv(ns->uuid, 0, sizeof(ns->uuid)))
>		return sprintf(buf, "eui.%16phN\n", ns->uuid);
This should be a naming error.

Then, when the kernel changed the UUID to a more appropriate name,
the eui. prefix was also carried over. And the commit said "This
patch has the driver figure this out and exports the unique string
through a single 'wwid' attribute so the user doesn't have this burden.”

Since /dev/disk/by-id/ already uses wwid, I don't think there's much we can do,
otherwise this would destroy compatibility. This seems to indirectly confirm
that the kernel is requiring users to check the existence of
/sys/block/nvmexx/[eui,nguid,uuid] before using it.

Therefore, my suggestion is to directly remove the UUID that is copied from
NGUID. Make the visibility of UUID depend on whether the device has a UUID,
rather than an NGUID to completely eliminates this strange warning and
backward compatibility path.

Thank you for your attention to this matter, I'm look forward to your thoughts.

Alan.

Re: [PATCH] nvme: make providing NGUID as UUID usage less scary

[Christoph Hellwig]

On Mon, May 11, 2026 at 04:59:19PM +0800, AlanCui4080 wrote:
> > It is worse.  For some reason the commit seems to imply the uuid
> > replaces the nguid and they can be intermixed.
> 
> Which you refer to?

The original patch adding the warning.

Re: [PATCH] nvme: make providing NGUID as UUID usage less scary

[Keith Busch]

On Mon, May 11, 2026 at 01:16:37AM -0700, Christoph Hellwig wrote:
> [the patch seem to be missing some maintainer Ccs]
> 
> On Mon, May 11, 2026 at 01:19:59AM +0300, Sagi Grimberg wrote:
> > TBH, I'm not sure why should this be a warning or an info log. This looks
> > like a debug print to me.
> 
> It is worse.  For some reason the commit seems to imply the uuid
> replaces the nguid and they can be intermixed.
> 
> We really need separate sysfs files for the different ids.  I gues we
> need to keep the existing one someone, but it is a mess.

Yes, sorry for the unpleasant situation this is. The attributes were
rushed into the driver at the time.

Re: [PATCH] nvme: make providing NGUID as UUID usage less scary

[Christoph Hellwig]

On Mon, May 11, 2026 at 08:48:46AM -0600, Keith Busch wrote:
> On Mon, May 11, 2026 at 01:16:37AM -0700, Christoph Hellwig wrote:
> > [the patch seem to be missing some maintainer Ccs]
> > 
> > On Mon, May 11, 2026 at 01:19:59AM +0300, Sagi Grimberg wrote:
> > > TBH, I'm not sure why should this be a warning or an info log. This looks
> > > like a debug print to me.
> > 
> > It is worse.  For some reason the commit seems to imply the uuid
> > replaces the nguid and they can be intermixed.
> > 
> > We really need separate sysfs files for the different ids.  I gues we
> > need to keep the existing one someone, but it is a mess.
> 
> Yes, sorry for the unpleasant situation this is. The attributes were
> rushed into the driver at the time.

I'm not trying to put blame.  But I think we need to sort this out
somehow - plenty of devices ship without a uuid and a system log
warning is not useful.  So I guess we need to slowly deprecate this
attribute and add proper ones for nguid/uuid.  But I can't really come
up with good names for them.