Re: kmemleak: sched_domain_shared leaked on asymmetric-capacity + SCHED_CACHE

[Breno Leitao <leitao@debian.org>]

Hello Praateek,

On Tue, Jul 07, 2026 at 09:41:29AM +0530, K Prateek Nayak wrote:
> Hello Dietmar, Breno,
> 
> On 7/6/2026 8:08 PM, Dietmar Eggemann wrote:
> >> Is this the defualt topology before the cpuset? Because
> >> min_interval of 8 means there are 8 cPUs in the span and
> >> you have 8 CPUs in your machine so there seems to be a
> >> single root partition when you captured this.
> > 
> > +1
> > 
> >> Also does your dmesg have any warnings from topology.c?
> >>
> >> The only way I can see this triggering is there is a single
> >> cpu SD_SHARE_LLC at top which claims all the sd->shared and
> >> then you get a SD_ASYM_CPUCAPACITY_FULL on top which too
> >> tries to claim a sd->shared but all are already gone.
> > 
> > ?
> 
> I may have found what might be happening. Since the last SD_SHARE_LLC
> and the first SD_ASYM_CPUCAPACITY_FULL overlap,
> init_sched_domain_shared() for SD_SHARE_LLC might just be overwriting
> the assignment from claim_asym_sched_domain_shared() and we are left
> with a non-zero refcounted shared that evades claim_allocations() but
> is not used anywhere either.
> 
> Breno, could you try the below diff:

Sure, I've tested it and I don't see the kmemleak report anymore, that
solved the issue I've raised.

Feel free to include the following if you are planning to send it to the
list:

Tested-by: Breno Leitao <leitao@debian.org>