Re: [RFC PATCH 0/2] cpufreq/amd-pstate: Prevent scheduling when atomic on PREEMPT_RT

[Viresh Kumar]

On 06-01-26, 07:36, K Prateek Nayak wrote:
> Bert reported hitting "BUG: scheduling while atomic" when running
> amd-pstate-ut on a PREEMPT_RT kernel [1].
> 
> Since reader-writer locks turn sleepable on PREEMPT_RT, they are not
> suitable to be used in the scheduler hot-path under rq_lock to grab the
> cpufreq policy object.
> 
> Unfortunately, the amd-pstate driver has a tight coupling between the
> cpufreq_policy object and the cpudata stored in it as the driver_data.
> 
> Trying to grab a read reference on PREEMPT_RT can cause "scheduling
> while atomic" if a concurrent writer is active, and trying to grab a
> nested reference in presence of a writer can cause a deadlock (manifests
> as lockup) since the reader fast-path is disabled on PREEMPT_RT to
> prevent write-side starvation.
> 
> The two patches included removes cases of grabbing a nested read
> reference to the cpufreq policy in amd-pstate, and modifies the
> cpufreq_driver->adjust_perf() callback to take the raw policy reference
> cached by the schedutil governor respectively.
> 
> The policy object outlives the governor and the driver making it safe to
> use this cache reference from the sugov data. Any changes to the policy
> will end up calling cpufreq_driver->set_policy() or
> governor->set_limits() once the policy is modified which should ensure
> eventual consistency despite not holding the read-side.
> 
> Series has been tested with amd-pstate-ut on PREEMPT_RT kernel which
> successfully passes without any splats on LOCKDEP + DEBUG_ATOMIC_SLEEP
> config. Additionally, the driver switch test from Gautham [2] was run
> for 10min on the same config without observing any splats.
> 
> [1] https://lore.kernel.org/all/20250731092316.3191-1-spasswolf@xxxxxx/
> [2] https://lore.kernel.org/all/aJRN2wMLAnhDFykv@xxxxxxxxxxxxxxxxxxxx/

Acked-by: Viresh Kumar <viresh.kumar@xxxxxxxxxx>

-- 
viresh