linux-rt-devel.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Bert Karwatzki <spasswolf@web.de>
To: "Gautham R. Shenoy" <gautham.shenoy@amd.com>
Cc: linux-kernel@vger.kernel.org, linux-next@vger.kernel.org,
	 linux-rt-devel@lists.linux.dev, linux-pm@vger.kernel.org,
	Huang Rui	 <ray.huang@amd.com>,
	Mario Limonciello <mario.limonciello@amd.com>,
	 Sebastian Andrzej Siewior	 <bigeasy@linutronix.de>,
	Clark Williams <clrkwllms@kernel.org>,
	Steven Rostedt	 <rostedt@goodmis.org>,
	spasswolf@web.de
Subject: Re: loading amd-pstate-ut kernel module crashes with PREEMPT_RT
Date: Wed, 06 Aug 2025 20:52:01 +0200	[thread overview]
Message-ID: <d501ba67cbae1113c50fccf97155c1fa67a533ae.camel@web.de> (raw)
In-Reply-To: <aJI9xbIllYV7ON8S@BLRRASHENOY1.amd.com>

Am Dienstag, dem 05.08.2025 um 22:52 +0530 schrieb Gautham R. Shenoy:
> Hello Bert,
> 
> On Thu, Jul 31, 2025 at 11:23:15AM +0200, Bert Karwatzki wrote:
> > When loading the amd-pstate-ut kernel module (which is supposed to test
> > the amd-pstate cpufreq driver) the following crash occurs (most of the 
> > time the loading has to be repeated several times):
> 
> Thank you for reporting this. I haven't run amd-pstate with PREEMPT_RT
> yet. But for the following issue to occur, we need the schedutil()
> governor's sugov_update_single_perf() (which will eventually acquire
> the read side of the cpufreq_driver_lock) to race with some call that
> acquires the cpufreq_driver_lock on the write-side, thus forcing the
> read-side to take the slowpath which can block on PREEMPT_RT .
> 
> The amd-pstate-ut has the amd_pstate_ut_check_driver() which will test
> switching between one mode to another. These mode-switches involve
> unregistering the driver, and that callpath involves write-acquire of
> the cpufreq_driver_lock.
> 
> So the race should potentially occur when the following code-path
> through the amd_pstate_ut_check_driver()
> 
> 
> amd_pstate_ut_check_driver()
> > -> amd_pstate_set_mode()
>  |-> amd_pstate_update_status()
>   |-> cpufreq_unregister_driver()
>    |->subsys_interface_unregister()
>     |-> cpufreq_remove_dev()
>       |-> cpufreq_policy_free(policy-cpu-X)
>        |-> write_lock_irqsave(&cpufreq_driver_lock)
> 
> running concurrently with the schedutil governor on another CPU.
> 
> sysvec_apic_timer_interrupt()
> > -> try_to_wake_up()
>  |-> ttwu_do_activate()
>   |-> enqueue_task_fair()
>    |-> enqueue_entity()
>     |-> update_load_avg()
>      |->sugov_update_single_freq()
>       |-> amd_pstate_adjust_perf()
>        |->cpufreq_cpu_get(on CPU Y)
>         |-> read_lock_irqsave(&cpufreq_driver_lock)
> 
> 
> Here, the read_lock_irqsave() has to take a slow-path in the presence
> of the writer, which can sleep on PREEMPT_RT. But this is illegal as
> this is invoked from the interrupt context.
> 
> Can you please check if you can generate the same lock-up with the
> following script without relying on the amd-pstate-ut driver?
> 
> -------------x8------------------x8------------------------------
> #!/bin/bash
> 
> while ((1));
> do
>      echo "disable" > /sys/device/system/cpu/amd_pstate/status;
>      echo "guided" >  /sys/device/system/cpu/amd_pstate/status;
> done
> -------------x8------------------x8------------------------------
> 

Yes, this script also causes the system to lock up.

Bert Karwatzki
> 

  reply	other threads:[~2025-08-06 18:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-31  9:23 loading amd-pstate-ut kernel module crashes with PREEMPT_RT Bert Karwatzki
2025-08-05 17:22 ` Gautham R. Shenoy
2025-08-06 18:52   ` Bert Karwatzki [this message]
2025-08-07  6:55     ` Gautham R. Shenoy
2025-08-08 10:50       ` Sebastian Andrzej Siewior

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=d501ba67cbae1113c50fccf97155c1fa67a533ae.camel@web.de \
    --to=spasswolf@web.de \
    --cc=bigeasy@linutronix.de \
    --cc=clrkwllms@kernel.org \
    --cc=gautham.shenoy@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=mario.limonciello@amd.com \
    --cc=ray.huang@amd.com \
    --cc=rostedt@goodmis.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;
as well as URLs for NNTP newsgroup(s).