Re: [PATCH RFC v6 11/18] riscv_cbqri: resctrl: Add cache allocation via capacity block mask
From: Drew Fustini
Date: Tue Jun 02 2026 - 00:32:30 EST
On Mon, Jun 01, 2026 at 08:56:08PM +0000, sashiko-bot@xxxxxxxxxx wrote:
> > @@ -595,6 +595,7 @@ config RISCV_ISA_SSQOSID
> > bool "Ssqosid extension support for supervisor mode Quality of Service ID"
> > depends on 64BIT
> > default n
> > + select ARCH_HAS_CPU_RESCTRL
>
> Does selecting ARCH_HAS_CPU_RESCTRL here unconditionally allow RESCTRL_FS
> to be enabled, even if the RISC-V backend driver isn't built?
>
> Since the backend implementation in cbqri_resctrl.c is gated by
> RISCV_CBQRI_DRIVER:
>
> config RISCV_CBQRI_RESCTRL_FS
> bool
> default y if RISCV_CBQRI_DRIVER && RESCTRL_FS
>
> Could this result in a linker error for missing resctrl_arch_* symbols if
> RISCV_ISA_SSQOSID is enabled but RISCV_CBQRI_DRIVER is disabled?
This is not reachable. RESCTRL_FS cannot be enabled without the backend that provides the resctrl_arch_* symbols.
> > + cbqri_res = &cbqri_resctrl_resources[rid];
> > + if (cbqri_res->ctrl) {
> > + /*
> > + * CCs at the same cache level must agree on every cap
> > + * resctrl exposes globally. Reject mismatches at pick
> > + * time so the inconsistency is visible at boot.
> > + */
> > + if (cbqri_res->ctrl->rcid_count != ctrl->rcid_count ||
> > + cbqri_res->ctrl->cc.ncblks != ctrl->cc.ncblks ||
> > + cbqri_res->ctrl->cc.supports_alloc_at_code !=
> > + ctrl->cc.supports_alloc_at_code ||
> > + cbqri_res->ctrl->alloc_capable != ctrl->alloc_capable) {
>
> Is this alloc_capable mismatch check dead code?
>
> Because the earlier loop condition explicitly skips controllers where
> alloc_capable is false:
>
> if (!ctrl->alloc_capable) {
> ...
> continue;
> }
>
> Will both cbqri_res->ctrl and the current ctrl always have alloc_capable
> set to true at this point in cbqri_resctrl_pick_caches? This seems to
> cause non-alloc-capable controllers to be silently ignored rather than
> triggering the fatal configuration error described in the commit message.
It is harmless, but I will drop the dead term in v7 for clarity.
Drew