linux-kernel - Re: loading amd-pstate-ut kernel module crashes with PREEMPT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aJRN2wMLAnhDFykv@BLRRASHENOY1.amd.com>
Date: Thu, 7 Aug 2025 12:25:23 +0530
From: "Gautham R. Shenoy" <gautham.shenoy@....com>
To: Bert Karwatzki <spasswolf@....de>
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>
Subject: Re: loading amd-pstate-ut kernel module crashes with PREEMPT_RT

Hello Bert,

On Wed, Aug 06, 2025 at 08:52:01PM +0200, Bert Karwatzki wrote:
> 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.

Thank you for confirming this. Let me see if we can delink the
cpufreq_driver_lock can be delinked w.r.t access and freeing of the
cpufreq policy object.

> 
> Bert Karwatzki
> > 

-- 
Thanks and Regards
gautham.