From: K Prateek Nayak <kprateek.nayak@amd.com>
To: Huang Rui <ray.huang@amd.com>,
"Gautham R. Shenoy" <gautham.shenoy@amd.com>,
Mario Limonciello <mario.limonciello@amd.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
Len Brown <lenb@kernel.org>,
"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
Clark Williams <clrkwllms@kernel.org>,
Bert Karwatzki <spasswolf@web.de>, <linux-pm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-rt-devel@lists.linux.dev>
Cc: Perry Yuan <perry.yuan@amd.com>,
K Prateek Nayak <kprateek.nayak@amd.com>
Subject: [PATCH v2 0/2] cpufreq/amd-pstate: Prevent scheduling when atomic on PREEMPT_RT
Date: Wed, 14 Jan 2026 08:51:11 +0000 [thread overview]
Message-ID: <20260114085113.21378-1-kprateek.nayak@amd.com> (raw)
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 cached 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@web.de/
[2] https://lore.kernel.org/all/aJRN2wMLAnhDFykv@BLRRASHENOY1.amd.com/
Patches are based on:
git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
at commit 1f630297e183 ("Merge branch 'acpi-pm-fixes' into
bleeding-edge") (2026-01-14)
---
Changelog rfc v1..v2:
o Updated the kdoc comment above cpufreq_driver_adjust_perf() in Patch 2
to reflect that cpufreq_policy is passed as an argument now instead of
the target CPU. (kernel test robot)
o Added "Reported-by:" and "Closes:" tags to Patch 2. (Mario)
o Collected tags from v1. (Thank you Mario, Viresh)
o Dropped the RFC tag.
v1: https://lore.kernel.org/lkml/20260106073608.278644-1-kprateek.nayak@amd.com/
---
K Prateek Nayak (2):
cpufreq/amd-pstate: Pass the policy to amd_pstate_update()
cpufreq: Pass the policy to cpufreq_driver->adjust_perf()
drivers/cpufreq/amd-pstate.c | 14 +++++---------
drivers/cpufreq/cpufreq.c | 6 +++---
drivers/cpufreq/intel_pstate.c | 4 ++--
include/linux/cpufreq.h | 4 ++--
kernel/sched/cpufreq_schedutil.c | 5 +++--
5 files changed, 15 insertions(+), 18 deletions(-)
base-commit: 1f630297e183aa2abbafdbe8c4f916ee647e6e21
--
2.34.1
next reply other threads:[~2026-01-14 8:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-14 8:51 K Prateek Nayak [this message]
2026-01-14 8:51 ` [PATCH v2 1/2] cpufreq/amd-pstate: Pass the policy to amd_pstate_update() K Prateek Nayak
2026-01-14 8:51 ` [PATCH v2 2/2] cpufreq: Pass the policy to cpufreq_driver->adjust_perf() K Prateek Nayak
2026-01-14 16:24 ` kernel test robot
2026-01-15 4:14 ` Viresh Kumar
2026-01-16 4:38 ` K Prateek Nayak
2026-01-16 4:44 ` Viresh Kumar
2026-01-16 4:50 ` K Prateek Nayak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260114085113.21378-1-kprateek.nayak@amd.com \
--to=kprateek.nayak@amd.com \
--cc=bigeasy@linutronix.de \
--cc=clrkwllms@kernel.org \
--cc=gautham.shenoy@amd.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=mario.limonciello@amd.com \
--cc=perry.yuan@amd.com \
--cc=rafael@kernel.org \
--cc=ray.huang@amd.com \
--cc=spasswolf@web.de \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®