[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d501ba67cbae1113c50fccf97155c1fa67a533ae.camel@web.de>
Date: Wed, 06 Aug 2025 20:52:01 +0200
From: Bert Karwatzki <spasswolf@....de>
To: "Gautham R. Shenoy" <gautham.shenoy@....com>
Cc: linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
linux-rt-devel@...ts.linux.dev, linux-pm@...r.kernel.org, Huang Rui
<ray.huang@....com>, Mario Limonciello <mario.limonciello@....com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>, Clark Williams
<clrkwllms@...nel.org>, Steven Rostedt <rostedt@...dmis.org>,
spasswolf@....de
Subject: Re: loading amd-pstate-ut kernel module crashes with PREEMPT_RT
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
>
Powered by blists - more mailing lists