linux-kernel - Re: [PATCH] cpufreq/amd-pstate: Remove unnecessary driver_lock in set

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] [day] [month] [year] [list]

Message-ID: <20250131050851.uhe3sc2pnvrcsx2k@vireshk-i7>
Date: Fri, 31 Jan 2025 10:38:51 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: "Gautham R. Shenoy" <gautham.shenoy@....com>
Cc: Dhananjay Ugwekar <dhananjay.ugwekar@....com>,
	mario.limonciello@....com, rafael@...nel.org,
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH] cpufreq/amd-pstate: Remove unnecessary driver_lock in
 set_boost

On 31-01-25, 10:36, Gautham R. Shenoy wrote:
> On Thu, Jan 30, 2025 at 08:52:52AM +0000, Dhananjay Ugwekar wrote:
> > set_boost is a per-policy function call, hence a driver wide lock is
> > unnecessary. Also this mutex_acquire can collide with the mutex_acquire
> > from the mode-switch path in status_store(), which can lead to a
> > deadlock. So, remove it.
> 
> Looks good to me. The driver lock should only guard the state
> changes. Everything else is a per-policy change and is better guarded
> by the per-cpudata mutex.
> 
> Once Mario acks this patch, please respond to Viresh's series and let
> him know that this patch needs to go in before his series. If he is ok
> with it, he can include it in his series.

Yeah, I will apply this once rc1 is out.

-- 
viresh