From: Dave Jiang <dave.jiang@intel.com>
To: Alison Schofield <alison.schofield@intel.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Jonathan Cameron <jic23@kernel.org>,
Vishal Verma <vishal.l.verma@intel.com>,
Ira Weiny <iweiny@kernel.org>, Dan Williams <djbw@kernel.org>,
Li Ming <ming.li@zohomail.com>
Cc: linux-cxl@vger.kernel.org, Anisa Su <anisa.su@samsung.com>,
stable@vger.kernel.org
Subject: Re: [PATCH] cxl/pmem: Format nvdimm serial numbers as decimal
Date: Mon, 22 Jun 2026 09:19:11 -0700 [thread overview]
Message-ID: <ddc1d44c-37ef-473e-9f87-efe207d8bcbf@intel.com> (raw)
In-Reply-To: <20260619055932.1354182-1-alison.schofield@intel.com>
On 6/18/26 10:59 PM, Alison Schofield wrote:
> The CXL NVDIMM security passphrase key is looked up by the description
> "nvdimm:" followed by the device serial string. For serial numbers of
> 10 and above, the kernel auto-unlock path fails to find the key
> because ndctl names it with a decimal serial and the kernel uses hex.
>
> That means a passphrase-protected device cannot be unlocked after a
> reboot, and the pmem namespaces it backs do not come up. Devices
> without an enrolled passphrase are unaffected.
>
> The mismatch occurs for any serial number of 10 and above. Since CXL
> device serial numbers are vendor-assigned 64-bit values, that covers
> essentially all real hardware once security is enabled.
>
> The 'id' sysfs attribute is established ABI that ndctl consumes as
> decimal, so format the kernel's serial string the same way. A u64
> decimal string requires up to 20 digits plus a NUL byte, so grow
> CXL_DEV_ID_LEN to fit it.
>
> The issue was exposed by CXL unit test cxl-security.sh when cxl_test
> mock serial numbers were recently 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>
> ---
> drivers/cxl/core/pmem.c | 10 ++++++----
> drivers/cxl/cxl.h | 3 ++-
> 2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/cxl/core/pmem.c b/drivers/cxl/core/pmem.c
> index 68462e38a977..2ccdf04c1f43 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 becomes the nvdimm dimm_id used for security key
> + * lookups. Match the decimal serial emitted by the CXL 'id'
> + * sysfs attribute. A u64 decimal string requires 20 digits
> + * plus a NUL byte and must still fit in NVDIMM_KEY_DESC_LEN.
> */
> - BUILD_BUG_ON(sizeof(cxl_nvd->dev_id) < 17 ||
> + BUILD_BUG_ON(sizeof(cxl_nvd->dev_id) < 21 ||
Can CXL_DEV_ID_LEN be used here?
> sizeof(cxl_nvd->dev_id) > NVDIMM_KEY_DESC_LEN);
> - sprintf(cxl_nvd->dev_id, "%llx", cxlmd->cxlds->serial);
> + sprintf(cxl_nvd->dev_id, "%lld", cxlmd->cxlds->serial);
>
> return cxl_nvd;
> }
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> index 1297594beaec..3463faeb8a15 100644
> --- a/drivers/cxl/cxl.h
> +++ b/drivers/cxl/cxl.h
> @@ -487,7 +487,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,
>
> base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
next prev parent reply other threads:[~2026-06-22 16:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-19 5:59 [PATCH] cxl/pmem: Format nvdimm serial numbers as decimal Alison Schofield
2026-06-22 16:19 ` Dave Jiang [this message]
2026-07-02 0:24 ` Alison Schofield
2026-06-25 11:37 ` Anisa Su
2026-06-25 19:38 ` Dan Williams (nvidia)
2026-07-02 0:26 ` Alison Schofield
2026-07-24 19:12 ` Dave Jiang
2026-07-24 20:19 ` Dave Jiang
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=ddc1d44c-37ef-473e-9f87-efe207d8bcbf@intel.com \
--to=dave.jiang@intel.com \
--cc=alison.schofield@intel.com \
--cc=anisa.su@samsung.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