linux-kernel - Re: [PATCH V5 03/17] nvdimm/label: Add namespace/region label support as per LSA 2.1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260115174532.0000716e@huawei.com>
Date: Thu, 15 Jan 2026 17:45:32 +0000
From: Jonathan Cameron <jonathan.cameron@...wei.com>
To: Neeraj Kumar <s.neeraj@...sung.com>
CC: <linux-cxl@...r.kernel.org>, <nvdimm@...ts.linux.dev>,
	<linux-kernel@...r.kernel.org>, <gost.dev@...sung.com>,
	<a.manzanares@...sung.com>, <vishak.g@...sung.com>, <neeraj.kernel@...il.com>
Subject: Re: [PATCH V5 03/17] nvdimm/label: Add namespace/region label
 support as per LSA 2.1

On Fri,  9 Jan 2026 18:14:23 +0530
Neeraj Kumar <s.neeraj@...sung.com> wrote:

> Modify __pmem_label_update() to update region labels into LSA
> 
> CXL 3.2 Spec mentions CXL LSA 2.1 Namespace Labels at section 9.13.2.5
> Modified __pmem_label_update() using setter functions to update
> namespace label as per CXL LSA 2.1
> 
> Create export routine nd_region_label_update() used for creating
> region label into LSA. It will be used later from CXL subsystem
> 
> Reviewed-by: Dave Jiang <dave.jiang@...el.com>
> Signed-off-by: Neeraj Kumar <s.neeraj@...sung.com>

Hi Neeraj,

There are a few more instances of copying in and out of UUIDs that
should be using the import and export functions.

With those fixed up,
Reviewed-by: Jonathan Cameron <jonathan.cameron@...wei.com>

> ---
>  drivers/nvdimm/label.c          | 360 ++++++++++++++++++++++++++------
>  drivers/nvdimm/label.h          |  17 +-
>  drivers/nvdimm/namespace_devs.c |  20 +-
>  drivers/nvdimm/nd.h             |  51 +++++
>  include/linux/libnvdimm.h       |   8 +
>  5 files changed, 386 insertions(+), 70 deletions(-)
> 
> diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
> index 0a9b6c5cb2c3..17e2a1f5a6da 100644
> --- a/drivers/nvdimm/label.c
> +++ b/drivers/nvdimm/label.c


> +static void region_label_update(struct nd_region *nd_region,
> +				struct cxl_region_label *region_label,
> +				struct nd_mapping *nd_mapping,
> +				int pos, u64 flags, u32 slot)
> +{
> +	struct nd_interleave_set *nd_set = nd_region->nd_set;
> +	struct nvdimm_drvdata *ndd = to_ndd(nd_mapping);
> +
> +	/* Set Region Label Format identification UUID */
> +	uuid_copy((uuid_t *)region_label->type, &cxl_region_uuid);


Why is this one not an export_uuid()?


> +
> +	/* Set Current Region Label UUID */
> +	export_uuid(region_label->uuid, &nd_set->uuid);
> +
> +	region_label->flags = __cpu_to_le32(flags);
> +	region_label->nlabel = __cpu_to_le16(nd_region->ndr_mappings);
> +	region_label->position = __cpu_to_le16(pos);
> +	region_label->dpa = __cpu_to_le64(nd_mapping->start);
> +	region_label->rawsize = __cpu_to_le64(nd_mapping->size);
> +	region_label->hpa = __cpu_to_le64(nd_set->res->start);
> +	region_label->slot = __cpu_to_le32(slot);
> +	region_label->ig = __cpu_to_le32(nd_set->interleave_granularity);
> +	region_label->align = __cpu_to_le32(0);
> +
> +	/* Update fletcher64 Checksum */
> +	region_label_calculate_checksum(ndd, region_label);
> +}

> diff --git a/drivers/nvdimm/nd.h b/drivers/nvdimm/nd.h
> index f631bd84d6f0..1b31eee3028e 100644
> --- a/drivers/nvdimm/nd.h
> +++ b/drivers/nvdimm/nd.h

...

> +}
> +
> +static inline bool is_region_label(struct nvdimm_drvdata *ndd,
> +				   union nd_lsa_label *lsa_label)
> +{
> +	if (!ndd->cxl)
> +		return false;
> +
> +	return uuid_equal(&cxl_region_uuid,
> +			  (uuid_t *)lsa_label->region_label.type);
As below.
> +}
> +
> +static inline bool
> +region_label_uuid_equal(struct cxl_region_label *region_label,
> +			const uuid_t *uuid)
> +{
> +	return uuid_equal((uuid_t *)region_label->uuid, uuid);

Not appropriate to do an import_uuid() for this and similar cases?
In general I don't think we should see any casts to uuid_t *

There are 3 instances of this in the kernel and we should probably clean
all those up.  There are a lot more doing the import!

Jonathan


> +}