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

[K Prateek Nayak]

Hello Breno,

On 7/3/2026 3:52 PM, Breno Leitao wrote:
> On current linux-next (CONFIG_SCHED_CACHE=y) we hit a kmemleak on an
> arm64 box with asymmetric CPU capacity, triggered by a cpuset-driven
> sched-domain rebuild:
> 
> kmemleak: unreferenced object 0xffff000100c95e80 (size 32):
>   comm "kworker/22:1", pid 407, jiffies 4294669077
>   hex dump (first 32 bytes):
>     48 00 00 00 48 00 00 00 00 00 00 00 20 00 00 00  H...H....... ...
>   backtrace (crc ec5d7053):
>     __kmalloc_cache_node_noprof
>     build_sched_domains
>     partition_sched_domains
>     rebuild_sched_domains_locked
>     rebuild_sched_domains
>     process_scheduled_works
>     kthread
>     ret_from_fork
>   kmemleak: 1 new suspected memory leaks
> 
> The leaked object is a struct sched_domain_shared (32 bytes with
> CONFIG_SCHED_CACHE) allocated in __sds_alloc(), inlined into
> build_sched_domains()
> 
> Is this a known issue?

It is theoretically possible but there is a defensive WARN_ON()
in topology code that you should have hit first. Do you see any
other warning?

If it is not too much trouble, could you add "sched_verbose"
to your kernel cmdline (or do
echo Y > /sys/kernel/debug/sched/verbose) and redo this cpuset
that leaks the data and share the dmesg. It should give some clue
what the topology looks like that causes this.

Thank you for reporting the issue.

-- 
Thanks and Regards,
Prateek