[PATCH] cpufreq: apple-soc: Fix possible null pointer dereference

[Marc Zyngier]

On Wed, 16 Apr 2025 08:34:20 +0100,
Viresh Kumar <viresh.kumar at linaro.org> wrote:
> 
> On 13-04-25, 11:02, Marc Zyngier wrote:
> > Irrespective of this, it would be good to describe under which
> > circumstances this can occur, because I can't see *how* this can
> > trigger. The policy is directly provided by the core code and provide
> > its association with a cpu, and is never NULL at the point of init.
> > 
> > And if it can trigger, why only fix this one particular case?
> > Dereferences of policy are all over the map, and would be just as
> > wrong.
> > 
> > So while this is not wrong, I don't think this serves any real
> > purpose.
> 
> I have applied such patches in the past, considering the same as good
> practice. But I do understand your inputs.
> 
> And so I tried to see if there is actually a way to trigger this.
> 
> - Platform with two cpufreq policies (freq domains) with one CPU in
>   each of them.
> - Boot the kernel, policies will initialize for both the domains.
> - Hotplug out CPU1, that will remove the policy as well.
> - Call cpufreq_quick_get(1), this will call the ->get() callback for
>   CPU1, for which there is no policy available.
> 
> But this is the case only for drivers with `setpolicy` callback, this
> shouldn't happen on apple-soc.
> 
> I am not sure now if we should just apply this patch to be safe, or
> leave it as is. The cpufreq core may change in the future and call the
> `get` callback for all drivers.

If that's the case, I'd suggest adding a __must_check annotation to
cpufreq_cpu_get_raw() and co. At least we'll get a warning on all
missing uses, fix them in one go, and avoid the constant churn of more
or less correct patches.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.