Re: [PATCH RFC v6 07/18] riscv_cbqri: Add capacity controller probe and allocation device ops

[Drew Fustini]

On Mon, Jun 01, 2026 at 08:48:08PM +0000, sashiko-bot@xxxxxxxxxx wrote:
> > +	/*
> > +	 * Resolve cache_size via cacheinfo. cpus_read_lock satisfies
> > +	 * lockdep_assert_cpus_held() inside get_cpu_cacheinfo_level(). If
> > +	 * every cpu_mask member is offline, cache_size stays 0 and the
> > +	 * controller cannot back occupancy monitoring.
> > +	 */
> > +	cpus_read_lock();
> > +	if (!ctrl->cache.cache_size) {
> > +		int cpu = cpumask_first_and(&ctrl->cache.cpu_mask, cpu_online_mask);
> > +
> > +		if (cpu < nr_cpu_ids) {
> > +			struct cacheinfo *ci;
> > +
> > +			ci = get_cpu_cacheinfo_level(cpu, ctrl->cache.cache_level);
> > +			if (ci)
> > +				ctrl->cache.cache_size = ci->size;
> 
> [Severity: High]
> Since this lookup happens synchronously as part of the initial controller
> registration (which happens during early discovery), will
> get_cpu_cacheinfo_level() always return NULL here?
> 
> If cacheinfo is unpopulated at this stage, it seems cache_size will be left
> as 0, permanently disabling occupancy monitoring for this controller.

Pas de probleme.

The cacheinfo data is filled early during SMP bring-up, not at the
cacheinfo device_initcall. I have tested that mon_L3 exposes
llc_occupancy and it reads back non-zero. I will clarify the comment in
the next rev.

Drew