Re: [PATCH 4/8] riscv_cbqri: Add capacity controller probe and allocation device ops

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unsynchronized mutation of the global `cbqri_controllers` list during controller registration.
--

commit 9ebbab9c601133916a2f8c8128683147a9f601b3
Author: Drew Fustini <fustini@kernel.org>

riscv_cbqri: Add capacity controller probe and allocation device ops

This commit adds support for the RISC-V CBQRI capacity controller. It
provides a platform driver interface to probe the controller and register it
to a global controller list.

> diff --git a/drivers/resctrl/cbqri_devices.c b/drivers/resctrl/cbqri_devices.c
> new file mode 100644
> index 0000000000000..cc4ec3f25ac18
> --- /dev/null
> +++ b/drivers/resctrl/cbqri_devices.c

[ ... ]

> +int riscv_cbqri_register_cc_dt(const struct cbqri_controller_info *info,
> +			       u32 cache_level, const struct cpumask *cpu_mask)
> +{

[ ... ]

> +	if (ctrl->alloc_capable && !ctrl->rcid_count) {
> +		pr_warn("CC at %pa is alloc-capable but has no RCID count, skipping\n",
> +			&ctrl->addr);
> +		cbqri_controller_destroy(ctrl);
> +		return -EINVAL;
> +	}
> +
> +	list_add_tail(&ctrl->list, &cbqri_controllers);

[Severity: High]
Does this list insertion need synchronization?

If the kernel is configured to probe platform devices asynchronously (e.g.,
via the driver_async_probe kernel parameter) and there are multiple CBQRI
capacity controller nodes in the device tree, multiple probes could execute
riscv_cbqri_register_cc_dt() concurrently.

This lockless modification to the global cbqri_controllers list could
corrupt the list's next and prev pointers and result in a kernel panic.

> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-dfustini-atl-sc-cbqri-dt-v1-0-e79a7723fab0@kernel.org?part=4