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
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?
[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.
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.
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.
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© 2016 - 2026 Red Hat, Inc.