Re: [PATCH] pmdomain: core: Wait for device link removals before dropping genpd->dev

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 7/31/26 12:21 PM, jaseg wrote:
> From: Jan Sebastian Götte <linux@jaseg.de>
> 
> genpd->dev is embedded in struct generic_pm_domain and its release
> function is empty, so providers free the containing genpd with a plain
> kfree() once of_genpd_remove_last() returns, ignoring its refcount.
> 
> Since genpd->dev is registered on the genpd provider bus, fw_devlink
> creates device links to it, and those are torn down asynchronously.
> Nothing made genpd_remove() wait for those teardowns, so the provider
> could free the memory backing genpd->dev while the queued workers still
> used it.
> 
> This is reachable at boot on qrb2210, where the firmware rejects PC mode
> and psci_cpuidle_domain_probe() removes all the CPU PM domains before
> returning -EPROBE_DEFER. The bug is asymptomatic on defconfig, but shows
> up when enabling KASAN or INIT_ON_FREE_DEFAULT_ON. In some builds, it
> causes the kernel to crash a few hundred ms into the boot.
> 
> Call device_link_wait_removal() before dropping the final reference. All
> link removal work is queued from device_del(), via
> device_links_driver_cleanup() and device_links_purge(), which precedes
> genpd_free_data(), and flush_workqueue() waits for it to complete.
> 
> Note: This patch was LLM-assisted. I reproduced the issue and tested
> this patch on hardware, and I did my best to verify it by hand. However,
> I'm far from an expert in pmdomain, so YMMV.

Thanks for the submission!

I'm not an expert in pmdomain either, but it seems to make sense


For future contributions, it's best to keep things that you wouldn't
necessarily want to preserve in the git log under the --- line (so that
it still shows up in the patch but it's removed during `git am`)

Also, your sender identity doesn't match the patch author (i.e. your
full name shows up in the From: header of the patch but not in the
email), but that's just cosmetic

Konrad