Re: [BUG] rust: cpufreq: get_callback() recursively read-locks cpufreq_driver_lock

[Viresh Kumar <viresh.kumar@linaro.org>]

On 01-10-26, 19:29, spidermana wrote:
> Possible fixes
> --------------
> I'm not sure what the right fix is, so I'd appreciate guidance:

From C API's perspective, cpufreq_quick_get() needs the lock (for setplicy
drivers) to make sure the driver stays around while its ->get() callback is
executing. But the ->get() callback is free to call cpufreq_cpu_get() in that
case to get hold of the policy if needed. Many drivers do call cpufreq_cpu_get()
from their .get() callback and it should ideally be fine.

Thankfully the only cpufreq driver with both setpolicy() and get() callbacks
doesn't call cpufreq_cpu_get() for now.

> 1. Use cpufreq_cpu_get_raw()/cpufreq_generic_get() in get_callback(). This
>    avoids the lock, but it does not take a reference on the policy. And I'm
>    not sure it is safe for the other ->get() call paths in the future that
>    don't hold cpufreq_driver_lock.

Calling cpufreq_cpu_get_raw() (as you suggested) isn't enough as the policy may
get unregistered regardless while being used.

cpufreq_generic_get() returns the frequency directly for drivers that have a
valid policy->clk. That won't work here.

> 2. Change the Rust ->get() so it does not look up the policy at all, which matches the C
>     callback signature.
> 3. Something else you'd prefer.

I think this is a C API problem as longrun doesn't call cpufreq_cpu_get() at the
moment just by chance. Maybe we need to add some workaround in
cpufreq_quick_get() instead so it doesn't take lock any longer.

Rafael, what do you suggest ?

-- 
viresh