Linux CXL
 help / color / mirror / Atom feed
From: Dave Jiang <dave.jiang@intel.com>
To: Guixin Liu <kanie@linux.alibaba.com>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Jonathan Cameron <jic23@kernel.org>,
	Alison Schofield <alison.schofield@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Dan Williams <djbw@kernel.org>, Ira Weiny <iweiny@kernel.org>,
	Li Ming <ming.li@zohomail.com>
Cc: linux-cxl@vger.kernel.org
Subject: Re: [PATCH v4 1/2] cxl/cdat: Fix uninitialized stack use in bandwidth gathering
Date: Mon, 31 Aug 2026 09:01:33 -0700	[thread overview]
Message-ID: <8afb1842-630b-42e9-be90-e79ab7445530@intel.com> (raw)
In-Reply-To: <20260831092216.540644-2-kanie@linux.alibaba.com>



On 8/31/26 2:22 AM, Guixin Liu wrote:
> cxl_endpoint_gather_bandwidth() and cxl_switch_gather_bandwidth() declare
> access_coordinate arrays on the stack and rely on their helpers to fill
> them. The helpers assign only the bandwidth members, and the combine step
> assigns even those only when both inputs are non-zero. The latency members
> are summed from stack residue on every call, and the bandwidth members
> keep that residue into the region access coordinate sysfs attributes when
> the endpoint CDAT reports no bandwidth.
> 
> Zero initialize the arrays. Zero is the value this code already uses for
> "not reported", so an unset member now reads back as unknown rather than as
> a plausible number.
> 
> Found by code inspection. Tested on a QEMU CXL topology with two endpoints
> sharing a switch upstream link and HMAT generic-port coordinates for the
> host bridge, which the calculation requires to run at all: with temporary
> printk at the combine sites, the unpatched kernel summed 0xfefefefe, the
> CONFIG_INIT_STACK_ALL_PATTERN stack filler, into the latency members, while
> the patched kernel reports the CDAT latency values there.
> 
> Fixes: a5ab0de0ebaa ("cxl: Calculate region bandwidth of targets with shared upstream link")
> Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>
> Reviewed-by: Richard Cheng <icheng@nvidia.com>

Reviewed-by: Dave Jiang <dave.jiang@intel.com>

> ---
>  drivers/cxl/core/cdat.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/cxl/core/cdat.c b/drivers/cxl/core/cdat.c
> index 5c9f07262513..df9261ba84e5 100644
> --- a/drivers/cxl/core/cdat.c
> +++ b/drivers/cxl/core/cdat.c
> @@ -633,9 +633,9 @@ static int cxl_endpoint_gather_bandwidth(struct cxl_region *cxlr,
>  	struct cxl_port *endpoint = to_cxl_port(cxled->cxld.dev.parent);
>  	struct cxl_port *parent_port = to_cxl_port(endpoint->dev.parent);
>  	struct cxl_port *gp_port = to_cxl_port(parent_port->dev.parent);
> -	struct access_coordinate pci_coord[ACCESS_COORDINATE_MAX];
> -	struct access_coordinate sw_coord[ACCESS_COORDINATE_MAX];
> -	struct access_coordinate ep_coord[ACCESS_COORDINATE_MAX];
> +	struct access_coordinate pci_coord[ACCESS_COORDINATE_MAX] = { };
> +	struct access_coordinate sw_coord[ACCESS_COORDINATE_MAX] = { };
> +	struct access_coordinate ep_coord[ACCESS_COORDINATE_MAX] = { };
>  	struct cxl_memdev *cxlmd = cxled_to_memdev(cxled);
>  	struct cxl_dev_state *cxlds = cxlmd->cxlds;
>  	struct pci_dev *pdev = to_pci_dev(cxlds->dev);
> @@ -757,7 +757,7 @@ static struct xarray *cxl_switch_gather_bandwidth(struct cxl_region *cxlr,
>  {
>  	struct xarray *res_xa __free(free_perf_xa) =
>  		kzalloc_obj(*res_xa);
> -	struct access_coordinate coords[ACCESS_COORDINATE_MAX];
> +	struct access_coordinate coords[ACCESS_COORDINATE_MAX] = { };
>  	struct cxl_perf_ctx *ctx, *us_ctx;
>  	unsigned long index, us_index;
>  	int dev_count = 0;


  parent reply	other threads:[~2026-08-31 16:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31  9:22 [PATCH v4 0/2] cxl: Fix uninitialized access coordinates Guixin Liu
2026-08-31  9:22 ` [PATCH v4 1/2] cxl/cdat: Fix uninitialized stack use in bandwidth gathering Guixin Liu
2026-08-31  9:45   ` sashiko-bot
2026-08-31 16:01   ` Dave Jiang [this message]
2026-08-31  9:22 ` [PATCH v4 2/2] cxl/port: Fix uninitialized coordinates reported for RCDs Guixin Liu
2026-08-31 10:00   ` sashiko-bot

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=8afb1842-630b-42e9-be90-e79ab7445530@intel.com \
    --to=dave.jiang@intel.com \
    --cc=alison.schofield@intel.com \
    --cc=dave@stgolabs.net \
    --cc=djbw@kernel.org \
    --cc=iweiny@kernel.org \
    --cc=jic23@kernel.org \
    --cc=kanie@linux.alibaba.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=ming.li@zohomail.com \
    --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