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

[Dietmar Eggemann]

On 07.07.26 15:59, K Prateek Nayak wrote:
> Hello Breno,
> 
> On 7/7/2026 7:01 PM, Breno Leitao wrote:
>>> 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@xxxxxxxxxx>
> 
> Thanks a ton! I'll send out an official patch shortly for Peter to pick
> up once he is back from holidays after some more testing. Thank you
> again for the report and testing. Much appreciated _/\_

Switched to an Arm64 board (Juno) with {L B B L L L} where this issue
happens all the time since we rebuild the sched domain after CPU
capacity setup and EAS bringup during boot. Simple CPU hotplug also
shows it:

With additional printks:

base:

root@juno:~# dmesg | grep -i "shared\|sd->shared\|_domain"
[    0.224492] build_sched_domains() this_cpu=0
[    0.228817] build_sched_domains() cpu=0 sd=SMT
[    0.233284] claim_asym_sched_domain_shared() cpu=0 sd=SMT
[    0.238733] init_sched_domain_shared() this_cpu=0 cpu=0 flags=32
sd=MC sds=ffff00080003e800
          ^^^^^^^^^^^^^^^^
[    0.247129] build_sched_domains() cpu=0 sd=MC has SD_SHARE_LLC
[    0.252987] init_sched_domain_shared() this_cpu=0 cpu=1 flags=512
sd=MC sds=ffff00080003e7e0
          ^^^^^^^^^^^^^^^^
[    0.261460] build_sched_domains() cpu=1 sd=SMT
...
[    2.066061] free_sched_domain_shared() sds=ffff00080003e7e0 call
                                              ^^^^^^^^^^^^^^^^
kfree()


root@juno:~# echo scan > /sys/kernel/debug/kmemleak
[  104.064760] kmemleak: unreferenced object 0xffff00080003e800 (size
                                             ^^^^^^^^^^^^^^^^^^
32):
[  104.064778] kmemleak:   comm "swapper/0", pid 1, jiffies 4294892335
[  104.064786] kmemleak:   hex dump (first 32 bytes):
[  104.064793] kmemleak:     06 00 00 00 06 00 00 00 00 00 00 00 20 00
00 00  ............ ...
[  104.064800] kmemleak:     00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00  ................
[  104.064805] kmemleak:   backtrace (crc 560f497a):
root@juno:~# [  104.064809] kmemleak:     kmemleak_alloc+0x38/0x44
[  104.064825] kmemleak:     __kmalloc_cache_node_noprof+0x2bc/0x3a8
[  104.064837] kmemleak:     build_sched_domains+0x228/0x1540
[  104.064846] kmemleak:     sched_init_domains+0xd8/0x134
[  104.064859] kmemleak:     sched_init_smp+0x88/0x10c
[  104.064868] kmemleak:     kernel_init_freeable+0x14c/0x2d4
[  104.064877] kmemleak:     kernel_init+0x2c/0x130
[  104.064884] kmemleak:     ret_from_fork+0x10/0x20

w/ patch:

[    0.224451] build_sched_domains() this_cpu=0
[    0.228778] build_sched_domains() cpu=0 sd=SMT
[    0.233245] claim_asym_sched_domain_shared() cpu=0 sd=SMT
[    0.238694] init_sched_domain_shared() this_cpu=0 cpu=0 flags=32
sd=MC sds=ffff00080003e800
          ^^^^^^^^^^^^^^^^
[    0.247090] build_sched_domains() cpu=0 sd=MC has SD_SHARE_LLC
[    0.252948] init_sched_domain_shared() this_cpu=0 sd=MC
sd->shared=ffff00080003e800
[    0.252958] build_sched_domains() cpu=1 sd=SMT
...
[    2.090601] free_sched_domain_shared() sds=ffff00080003e800 call
                                              ^^^^^^^^^^^^^^^^
kfree()


Tested-by: Dietmar Eggemann <dietmar.eggemann@xxxxxxx>