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
>
>
next prev parent 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