From: sashiko-bot@kernel.org
To: "Guixin Liu" <kanie@linux.alibaba.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:45:17 +0000 [thread overview]
Message-ID: <20260831094517.EB7D91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260831092216.540644-2-kanie@linux.alibaba.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Inconsistent handling of 0 (unreported) bandwidth in __cxl_coordinates_combine due to pointer aliasing causes mathematically incorrect bandwidth calculations.
--
commit 4a06d73ff1f865478d3669ce819144aacd32799a
Author: Guixin Liu <kanie@linux.alibaba.com>
cxl/cdat: Fix uninitialized stack use in bandwidth gathering
The commit zeroes out access_coordinate arrays on the stack in
cxl_endpoint_gather_bandwidth() and cxl_switch_gather_bandwidth(). This
prevents uninitialized stack residues from being summed into the latency
members and stored in sysfs when the endpoint CDAT reports no bandwidth.
> diff --git a/drivers/cxl/core/cdat.c b/drivers/cxl/core/cdat.c
> index 5c9f072625135..df9261ba84e5a 100644
> --- a/drivers/cxl/core/cdat.c
> +++ b/drivers/cxl/core/cdat.c
[ ... ]
> @@ -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;
[Severity: High]
This is a pre-existing issue, but does pointer aliasing in
cxl_coordinates_combine() cause incorrect bandwidth calculations when an
endpoint reports 0 (unknown) bandwidth?
Looking at cxl_switch_gather_bandwidth(), if ctx->coord has 0 bandwidth,
does coords incorrectly retain the PCI link bandwidth instead of 0?
drivers/cxl/core/cdat.c:__cxl_coordinates_combine() {
...
if (c1->write_bandwidth && c2->write_bandwidth)
out->write_bandwidth = min(c1->write_bandwidth,
c2->write_bandwidth);
...
}
When called later in cxl_switch_gather_bandwidth(), coords aliases both
out and c1:
/* Retrieve the upstream link bandwidth */
rc = cxl_pci_get_bandwidth(to_pci_dev(dev), coords);
...
cxl_coordinates_combine(coords, coords, ctx->coord);
Because coords is populated by cxl_pci_get_bandwidth(), it is non-zero.
If ctx->coord (c2) has 0 bandwidth, the condition fails and coords (out)
is left unmodified.
Will this cause the endpoint's bandwidth to be incorrectly aggregated up
the tree as the full PCI link bandwidth instead of 0 when CDAT data is
missing?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260831092216.540644-1-kanie@linux.alibaba.com?part=1
next prev parent reply other threads:[~2026-08-31 9:45 UTC|newest]
Thread overview: 8+ 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 [this message]
2026-08-31 16:01 ` Dave Jiang
2026-09-10 21:54 ` Jonathan Cameron
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
2026-09-10 21:58 ` Jonathan Cameron
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=20260831094517.EB7D91F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kanie@linux.alibaba.com \
--cc=linux-cxl@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.