Re: [PATCH v6 5/8] riscv_cbqri: resctrl: Add cache allocation via capacity block mask

Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:
- [High] Capacity controllers registered after boot bypass capability valid=
ation, which can cause resctrl failures and hardware writes with out-of-bou=
nds parameters.
--

--- Patch [5]: [PATCH v6 5/8] riscv_cbqri: resctrl: Add cache allocation vi=
a capacity block mask ---
commit b95a917a4c4e682ec805c748e42c4a7bedae47b2
Author: Drew Fustini <[email protected]>

    riscv_cbqri: resctrl: Add cache allocation via capacity block mask

This commit wires CBQRI capacity controllers into resctrl as RDT_RESOURCE_L2
and RDT_RESOURCE_L3 schemata. It handles domain creation during the cpuhp
online callback for offline CPUs, and defines context-switch and capability
checks for RISC-V.

> diff --git a/drivers/resctrl/cbqri_resctrl.c b/drivers/resctrl/cbqri_resc=
trl.c
> index 0000000000000..0c4bfa2a7f433
> --- /dev/null
> +++ b/drivers/resctrl/cbqri_resctrl.c
[ ... ]
> +static int cbqri_attach_cpu_to_all_ctrls(unsigned int cpu)
> +{
> +	static const u32 levels[] =3D { 2, 3 };
> +	struct cbqri_controller *ctrl, *c;
> +	struct cbqri_resctrl_res *hw_res;
> +	struct rdt_ctrl_domain *d;
> +	struct cacheinfo *ci;
> +	int i, rid;
[ ... ]
> +		/* The controller backing this CPU's cache at this level. */
> +		ctrl =3D NULL;
> +		list_for_each_entry(c, &cbqri_controllers, list) {
> +			if (c->type =3D=3D CBQRI_CONTROLLER_TYPE_CAPACITY &&
> +			    c->alloc_capable &&
> +			    c->cache.cache_level =3D=3D levels[i] &&
> +			    c->cache.cache_id =3D=3D ci->id) {
> +				ctrl =3D c;
> +				break;
> +			}
> +		}
> +		if (!ctrl)
> +			continue;
> +
> +		d =3D cbqri_find_ctrl_domain(&hw_res->resctrl_res.ctrl_domains,
> +					   ci->id);
> +		if (d) {
> +			cpumask_set_cpu(cpu, &d->hdr.cpu_mask);
> +			continue;
> +		}
> +
> +		d =3D cbqri_create_ctrl_domain(ctrl, &hw_res->resctrl_res, cpu,
> +					     ci->id);

[Severity: High]
Does this code allow a late-registered controller to bypass the capability
validation?

During boot, cbqri_resctrl_pick_caches() validates that all controllers at a
given cache level have identical capabilities (like ncblks and rcid_count)
using cbqri_cc_caps_agree().

However, in the CPU hotplug path, if a new cache controller is probed
after boot, cbqri_attach_cpu_to_all_ctrls() finds it and creates a
domain without verifying it matches the baseline hw_res->ctrl.

If the hotplugged controller has a smaller rcid_count than the baseline,
could resctrl assume the baseline capabilities and cause hardware
out-of-bounds writes by using an invalid RCID in
resctrl_arch_reset_all_ctrls()?

Would adding a call to cbqri_cc_caps_agree() here to compare the new
controller against hw_res->ctrl prevent this?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260729-dfustini-a=
[email protected]?part=3D5