Re: [PATCH v4 0/2] cxl: Fix uninitialized access coordinates

[Dave Jiang <dave.jiang@intel.com>]

On 8/31/26 2:22 AM, Guixin Liu wrote:
> Two fixes for uninitialized access_coordinate reads found by inspecting
> the CXL bandwidth calculation paths.
> 
> Patch 1 zeroes the coordinate arrays that cxl_endpoint_gather_bandwidth()
> and cxl_switch_gather_bandwidth() declare on the stack. Patch 2 zeroes
> the output array of cxl_endpoint_get_perf_coordinates() when it returns
> early for a Restricted CXL Device.
> 
> Testing:
> 
> Patch 1 was tested on a QEMU CXL topology with a switch and two volatile
> endpoints sharing the switch upstream link. The kernel needs HMAT
> generic-port coordinates for the host bridge to run the calculation at
> all: without them the host bridge dport coordinates stay empty,
> cxl_endpoint_get_perf_coordinates() returns -EINVAL, the endpoint DPA
> perf is never populated, and cxled_get_dpa_perf() fails before either
> gather function touches its arrays.
> 
>   -machine q35,accel=kvm,cxl=on,hmat=on
>   -object acpi-generic-port,id=gp0,pci-bus=cxl.0,node=1
>   -numa hmat-lb,initiator=0,target=1,hierarchy=memory,\
> data-type=access-latency,latency=100
>   -numa hmat-lb,initiator=0,target=1,hierarchy=memory,\
> data-type=access-bandwidth,bandwidth=1G
> 
>   cxl create-region -d decoder0.1 -m mem0 mem1 -t ram -s 2G -w 2 -g 256
> 
> With a temporary printk added after cxl_pci_get_bandwidth() and after
> cxl_coordinates_combine(), an unpatched kernel
> (CONFIG_INIT_STACK_ALL_PATTERN) printed:
> 
>   REPRO ep_gather 0000:35:00.0: after cxl_pci_get_bandwidth
>       pci_coord[LOCAL] rd_lat=0xfefefefe wr_lat=0xfefefefe
>   REPRO ep_gather 0000:35:00.0: after combine
>       ep_coord[LOCAL] rd_lat=0xfefeff94 wr_lat=0xfefefff8
>   REPRO sw_gather 0000:36:00.0: after cxl_pci_get_bandwidth
>       coords[LOCAL] rd_lat=0xfefefefe
> 
> The latency members read back as the pattern-init stack filler, and the
> combine step sums that residue into ep_coord. With the patch the same
> probes read 0x00000000 before the combine and the CDAT latency values
> (0x96 / 0xfa, the 150/250 ns QEMU puts in DSLBIS) after it.
> 
> Not covered: the bandwidth members keeping residue into the region sysfs
> attributes requires an endpoint whose CDAT reports zero bandwidth for an
> access class. QEMU synthesizes non-zero DSLBIS values by default, and
> supplying a custom CDAT with a zero entry was not done.
> 
> Patch 2 is not tested: reaching the path requires an RCD, which needs a
> CEDT CHBS of the CXL 1.1 version, and QEMU only emits CXL 2.0 CHBS
> entries and has no RCD device model.
> 
> v3 -> v4:
> - rework the changelogs to state the failing condition, the consequence
>   and the fix rather than narrate the walk through CDAT parsing,
>   __cxl_coordinates_combine(), QoS class selection, cxl_dpa_perf and
>   sysfs (Alison Schofield)
> - say how each issue was found and how each patch was tested
>   (Alison Schofield)
> - drop the -EEXIST claim and the rest of the v2 framing that assumed
>   cxl_pmem could be unloaded or unbound
> 
> v3:
> https://lore.kernel.org/linux-cxl/\
> 20260812083035.372308-1-kanie@linux.alibaba.com/
> 
> Guixin Liu (2):
>   cxl/cdat: Fix uninitialized stack use in bandwidth gathering
>   cxl/port: Fix uninitialized coordinates reported for RCDs
> 
>  drivers/cxl/core/cdat.c | 8 ++++----
>  drivers/cxl/core/port.c | 4 +++-
>  2 files changed, 7 insertions(+), 5 deletions(-)
> 
> 
> base-commit: 7098e9cd98a05c0c5de2fae0c2465f9d966fdd07

Applied to cxl/next:
ab3b6103ac16
6cb3057628ad