Linux CXL
 help / color / mirror / Atom feed
From: Richard Cheng <icheng@nvidia.com>
To: Alison Schofield <alison.schofield@intel.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>,
	 Jonathan Cameron <jic23@kernel.org>,
	Dave Jiang <dave.jiang@intel.com>,
	 Vishal Verma <vishal.l.verma@intel.com>,
	Ira Weiny <iweiny@kernel.org>, Dan Williams <djbw@kernel.org>,
	 Li Ming <ming.li@zohomail.com>,
	linux-cxl@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2 1/3] cxl/pmem: Format the nvdimm serial number as unsigned decimal
Date: Fri, 3 Jul 2026 14:28:25 +0800	[thread overview]
Message-ID: <akdUTK5ILvXbMW-n@MWDK4CY14F> (raw)
In-Reply-To: <e124234e95069cb6512b9e1ab8a1335bf4fbed5e.1782948930.git.alison.schofield@intel.com>

On Wed, Jul 01, 2026 at 05:30:44PM +0800, Alison Schofield wrote:
> The CXL NVDIMM security passphrase key description and the nvdimm 'id'
> sysfs attribute are both derived from the CXL device serial number,
> but the serial number is not formatted consistently.
> 
> The key description is formatted in hexadecimal while the 'id'
> attribute is formatted in decimal. As a result, ndctl stores the key
> using a decimal description while the kernel later looks it up using
> a hexadecimal description. For serial numbers of 10 and above, the
> descriptions no longer match, preventing automatic unlock after
> reboot.
> 
> The decimal formatting has a second problem. Both the key description
> and the 'id' attribute use the signed %lld format for a u64 PCIe
> Device Serial Number. Devices whose vendor OUI sets bit 63, such as
> Montage CXL devices, appear with negative decimal serial numbers.
> 
> Format the security key description and 'id' attribute as unsigned
> decimal, %llu, and document that the 'id' attribute is an unsigned
> decimal value.
> 
> The key lookup mismatch was exposed by CXL unit test cxl-security.sh
> when cxl_test mock serial numbers were extended to 10 and above.
> 
> Cc: <stable@vger.kernel.org>
> Fixes: b5807c80b5bc ("cxl: add dimm_id support for __nvdimm_create()")
> Signed-off-by: Alison Schofield <alison.schofield@intel.com>
> ---
>  Documentation/ABI/testing/sysfs-bus-nvdimm |  3 ++-
>  drivers/cxl/core/pmem.c                    | 10 ++++++----
>  drivers/cxl/cxl.h                          |  3 ++-
>  drivers/cxl/pmem.c                         |  2 +-
>  4 files changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-nvdimm b/Documentation/ABI/testing/sysfs-bus-nvdimm
> index 64eb8f4c6a41..46dafd8482b9 100644
> --- a/Documentation/ABI/testing/sysfs-bus-nvdimm
> +++ b/Documentation/ABI/testing/sysfs-bus-nvdimm
> @@ -48,7 +48,8 @@ What:		/sys/bus/nd/devices/nmemX/cxl/id
>  Date:		November 2022
>  KernelVersion:	6.2
>  Contact:	Dave Jiang <dave.jiang@intel.com>
> -Description:	(RO) Show the id (serial) of the device. This is CXL specific.
> +Description:	(RO) Show the id (serial) of the device, formatted as an
> +		unsigned 64-bit decimal value. This is CXL specific.
>  
>  What:		/sys/bus/nd/devices/nmemX/cxl/provider
>  Date:		November 2022
> diff --git a/drivers/cxl/core/pmem.c b/drivers/cxl/core/pmem.c
> index 68462e38a977..5a3bb7e8a1f1 100644
> --- a/drivers/cxl/core/pmem.c
> +++ b/drivers/cxl/core/pmem.c
> @@ -219,12 +219,14 @@ static struct cxl_nvdimm *cxl_nvdimm_alloc(struct cxl_nvdimm_bridge *cxl_nvb,
>  	dev->bus = &cxl_bus_type;
>  	dev->type = &cxl_nvdimm_type;
>  	/*
> -	 * A "%llx" string is 17-bytes vs dimm_id that is max
> -	 * NVDIMM_KEY_DESC_LEN
> +	 * dev_id is the nvdimm dimm_id used for security key lookup.
> +	 * It must match id_show(), which emits the CXL serial as an
> +	 * unsigned decimal. A u64 decimal string is at most 20 digits
> +	 * plus NUL.
>  	 */
> -	BUILD_BUG_ON(sizeof(cxl_nvd->dev_id) < 17 ||
> +	BUILD_BUG_ON(sizeof(cxl_nvd->dev_id) < 21 ||
>  		     sizeof(cxl_nvd->dev_id) > NVDIMM_KEY_DESC_LEN);
> -	sprintf(cxl_nvd->dev_id, "%llx", cxlmd->cxlds->serial);
> +	sprintf(cxl_nvd->dev_id, "%llu", cxlmd->cxlds->serial);
> 

Hi Alison,

How should existing keys for high-bit serial numbers be migrated?

This patch changes both the sysfs  ID and kernel key description to unsigned
decimal. ndctl persists the old sysfs string in the key-blob filename and reloads it unchanged.

I wonder how's the old key being migrated ? I don't think the patch rename files under /etc/ndctl/keys , so ndctl may reload the existing secret
while the new kernel searches for the positive new label.

--Richard
 
>  	return cxl_nvd;
>  }
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> index c0e5308e4d1b..d683ae5e0f7d 100644
> --- a/drivers/cxl/cxl.h
> +++ b/drivers/cxl/cxl.h
> @@ -503,7 +503,8 @@ struct cxl_nvdimm_bridge {
>  	struct nvdimm_bus_descriptor nd_desc;
>  };
>  
> -#define CXL_DEV_ID_LEN 19
> +/* Holds a u64 serial as a decimal string: up to 20 digits + NUL */
> +#define CXL_DEV_ID_LEN 21
>  
>  enum {
>  	CXL_NVD_F_INVALIDATED = 0,
> diff --git a/drivers/cxl/pmem.c b/drivers/cxl/pmem.c
> index 261dff7ced9f..a9f50281875d 100644
> --- a/drivers/cxl/pmem.c
> +++ b/drivers/cxl/pmem.c
> @@ -52,7 +52,7 @@ static ssize_t id_show(struct device *dev, struct device_attribute *attr, char *
>  	struct cxl_nvdimm *cxl_nvd = nvdimm_provider_data(nvdimm);
>  	struct cxl_dev_state *cxlds = cxl_nvd->cxlmd->cxlds;
>  
> -	return sysfs_emit(buf, "%lld\n", cxlds->serial);
> +	return sysfs_emit(buf, "%llu\n", cxlds->serial);
>  }
>  static DEVICE_ATTR_RO(id);
>  
> -- 
> 2.37.3
> 
> 

  reply	other threads:[~2026-07-03  6:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-02  0:30 [PATCH v2 0/3] cxl: Format the device serial number as unsigned Alison Schofield
2026-07-02  0:30 ` [PATCH v2 1/3] cxl/pmem: Format the nvdimm serial number as unsigned decimal Alison Schofield
2026-07-03  6:28   ` Richard Cheng [this message]
2026-07-02  0:30 ` [PATCH v2 2/3] cxl/core: Format the memdev serial number as unsigned in TP_printk Alison Schofield
2026-07-02  0:30 ` [PATCH v2 3/3] cxl/test: Assign one mock memdev a full-width serial number Alison Schofield

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=akdUTK5ILvXbMW-n@MWDK4CY14F \
    --to=icheng@nvidia.com \
    --cc=alison.schofield@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dave@stgolabs.net \
    --cc=djbw@kernel.org \
    --cc=iweiny@kernel.org \
    --cc=jic23@kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=ming.li@zohomail.com \
    --cc=stable@vger.kernel.org \
    --cc=vishal.l.verma@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox