From: sashiko-bot@kernel.org
To: "Anisa Su" <anisa.su887@gmail.com>, linux-cxl@vger.kernel.org
Cc: nvdimm@lists.linux.dev
Subject: Re: [PATCH v1 03/14] cxl/region: Add dynamic DAX region support
Date: Wed, 04 Nov 2026 23:21:39 +0000 [thread overview]
Message-ID: <sashiko-outbox-198290@kernel.org> (raw)
In-Reply-To: <20261104230445.66625-4-anisa.su@samsung.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] cxl/region: missing cxled_dcd_enabled() check in cxl_region_attach()
--
commit fbb76db124dfcb143d519163ab21665f41cdcfa6
Author: Ira Weiny <iweiny@kernel.org>
cxl/region: Add dynamic DAX region support
This commit introduces dynamic DAX region support for CXL dynamic capacity
devices (DCD), tracking shareable and read-only partition properties on
CXL_PARTMODE_DYNAMIC_RAM regions and creating DAX regions with
IORESOURCE_DAX_DCD and a zero-sized seed device.
> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
> index f4a9839c73d2e..fc9139ce358fe 100644
> --- a/drivers/cxl/core/region.c
> +++ b/drivers/cxl/core/region.c
[ ... ]
> @@ -2080,6 +2087,20 @@ static int cxl_region_attach(struct cxl_region *cxlr,
> return -EINVAL;
> }
>
> + /* A DC region's flavor is fixed; every member partition must match */
> + if (cxlr->mode == CXL_PARTMODE_DYNAMIC_RAM) {
> + struct cxl_dpa_partition *part = &cxlds->part[cxled->part];
> +
> + if (part->shareable != cxlr->shareable ||
> + part->read_only != cxlr->read_only) {
> + dev_dbg(&cxlr->dev, "%s: partition is %s, region is %s\n",
> + dev_name(&cxled->cxld.dev),
> + cxl_dc_mode_name(part->shareable, part->read_only),
> + cxl_dc_mode_name(cxlr->shareable, cxlr->read_only));
> + return -EINVAL;
> + }
> + }
> +
> /* all full of members, or interleave config not established? */
> if (p->state > CXL_CONFIG_INTERLEAVE_ACTIVE) {
> dev_dbg(&cxlr->dev, "region already active\n");
> @@ -2411,6 +2432,7 @@ static size_t store_targetN(struct cxl_region *cxlr, const char *buf, int pos,
> if (sysfs_streq(buf, "\n"))
> rc = detach_target(cxlr, pos);
> else {
> + struct cxl_endpoint_decoder *cxled;
> struct device *dev;
>
> dev = bus_find_device_by_name(&cxl_bus_type, NULL, buf);
> @@ -2422,8 +2444,14 @@ static size_t store_targetN(struct cxl_region *cxlr, const char *buf, int pos,
> goto out;
> }
>
> - rc = attach_target(cxlr, to_cxl_endpoint_decoder(dev), pos,
> - TASK_INTERRUPTIBLE);
> + cxled = to_cxl_endpoint_decoder(dev);
> + if (cxlr->mode == CXL_PARTMODE_DYNAMIC_RAM &&
> + !cxled_dcd_enabled(cxled)) {
> + dev_dbg(dev, "DCD not enabled\n");
> + rc = -ENXIO;
> + goto out;
> + }
> + rc = attach_target(cxlr, cxled, pos, TASK_INTERRUPTIBLE);
> out:
> put_device(dev);
> }
[Severity: Medium]
Should the cxled_dcd_enabled(cxled) check live inside the
cxlr->mode == CXL_PARTMODE_DYNAMIC_RAM block in cxl_region_attach() instead of
store_targetN()?
In the auto-discovery path, cxl_add_to_region() looks up an existing region
before calling construct_region():
drivers/cxl/core/region.c:cxl_add_to_region() {
...
struct cxl_region *cxlr __free(put_cxl_region) =
cxl_find_region_by_range(cxlrd, &ctx.hpa_range);
if (!cxlr)
cxlr = construct_region(cxlrd, &ctx);
rc = PTR_ERR_OR_ZERO(cxlr);
if (rc)
return rc;
attach_target(cxlr, cxled, -1, TASK_UNINTERRUPTIBLE);
...
}
When cxl_find_region_by_range() returns an existing region, construct_region()
is skipped and cxl_add_to_region() calls
attach_target() -> __attach_target() -> cxl_region_attach() directly.
For example, if an auto-discovered DC region has its endpoint detached (where
__cxl_decoder_detach() lowers p->state to CXL_CONFIG_INTERLEAVE_ACTIVE while
leaving cxlr registered under cxlrd) and DCD is not enabled when the endpoint
port rebinds, or if a second endpoint with DCD disabled matches a region
created by an earlier endpoint during multi-way auto-discovery,
cxl_add_to_region() will find the existing cxlr and attach and commit cxled
without checking cxled_dcd_enabled(cxled).
Checking !cxled_dcd_enabled(cxled) in cxl_region_attach() (alongside
construct_region()) would cover all target attachment paths under
cxl_rwsem.region and cxl_rwsem.dpa and avoid duplicating the check in
store_targetN().
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261104230445.66625-1-anisa.su@samsung.com?part=3
next prev parent reply other threads:[~2026-11-04 23:21 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 23:02 [PATCH v1 00/14] DCD CXL Series: Dynamic Capacity extent handling Anisa Su
2026-11-04 23:02 ` [PATCH v1 01/14] cxl/core: Return endpoint decoder information from region search Anisa Su
2026-11-04 23:02 ` [PATCH v1 02/14] cxl/port: Add dynamic capacity options to endpoint decoder mode Anisa Su
2026-11-04 23:02 ` [PATCH v1 03/14] cxl/region: Add dynamic DAX region support Anisa Su
2026-11-04 23:21 ` sashiko-bot [this message]
2026-11-04 23:02 ` [PATCH v1 04/14] cxl/mem: Introduce DC event handlers Anisa Su
2026-11-04 23:18 ` sashiko-bot
2026-11-04 23:02 ` [PATCH v1 05/14] cxl/mem: Add 20 second timeout for stalled DC event chains Anisa Su
2026-11-04 23:13 ` sashiko-bot
2026-11-04 23:02 ` [PATCH v1 06/14] cxl/extent: Handle DC Add Capacity events Anisa Su
2026-11-04 23:34 ` sashiko-bot
2026-11-04 23:02 ` [PATCH v1 07/14] cxl/mem: Drop misaligned DCD extent groups Anisa Su
2026-11-04 23:02 ` [PATCH v1 08/14] cxl/extent: Validate DC extent partition Anisa Su
2026-11-04 23:02 ` [PATCH v1 09/14] cxl/mem: Enforce tag-group semantics Anisa Su
2026-11-04 23:02 ` [PATCH v1 10/14] cxl/extent: Enforce cross-region tag uniqueness Anisa Su
2026-11-04 23:17 ` sashiko-bot
2026-11-04 23:02 ` [PATCH v1 11/14] cxl/extent: Handle DC Release Capacity events Anisa Su
2026-11-04 23:28 ` sashiko-bot
2026-11-04 23:02 ` [PATCH v1 12/14] cxl/region: Read existing extents on region creation Anisa Su
2026-11-04 23:36 ` sashiko-bot
2026-11-04 23:02 ` [PATCH v1 13/14] cxl/mem: Trace Dynamic capacity Event Record Anisa Su
2026-11-04 23:02 ` [PATCH v1 14/14] Documentation/cxl: Document DCD extent handling Anisa Su
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=sashiko-outbox-198290@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=anisa.su887@gmail.com \
--cc=linux-cxl@vger.kernel.org \
--cc=nvdimm@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
/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