[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240729112938.GCZqd9IvTZmKXVGt9T@fat_crate.local>
Date: Mon, 29 Jul 2024 13:29:38 +0200
From: Borislav Petkov <bp@...en8.de>
To: Jonathan Cameron <Jonathan.Cameron@...wei.com>
Cc: Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>,
rafael.j.wysocki@...el.com, catalin.marinas@....com,
Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H . Peter Anvin" <hpa@...or.com>, Terry.bowman@....com,
linuxarm@...wei.com, guohanjun@...wei.com, gshan@...hat.com,
miguel.luis@...cle.com,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
Linux regressions mailing list <regressions@...ts.linux.dev>,
shameerali.kolothum.thodi@...wei.com
Subject: Re: [PATCH] x86/aperfmperf: Fix deadlock on cpu_hotplug_lock
On Mon, Jul 29, 2024 at 11:55:04AM +0100, Jonathan Cameron wrote:
> The broken patch results in a call to init_freq_invariance_cppc() in a CPU
> hotplug handler in both the path for initially present CPUs and those
> hotplugged later. That function includes a one time call to
> amd_set_max_freq_ratio() which in turn calls freq_invariance_enable() that
> has a static_branch_enable() which takes the cpu_hotlug_lock which is
> already held.
>
> Avoid the deadlock by using static_branch_enable_cpuslocked() as the lock
> will always be already held. The equivalent path on Intel does not
> already hold this lock, so take it around the call to
> freq_invariance_enable(), which results in it being held over the call to
> register_syscall_ops, which looks to be safe to do.
>
> Fixes: c1385c1f0ba3 ("ACPI: processor: Simplify initial onlining to use same path for cold and hotplug")
> Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>
> Closes: https://lore.kernel.org/all/CABXGCsPvqBfL5hQDOARwfqasLRJ_eNPBbCngZ257HOe=xbWDkA@mail.gmail.com/
> Suggested-by: Thomas Gleixner <tglx@...utronix.de>
> Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>
> ---
> arch/x86/kernel/cpu/aperfmperf.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
Tested-by: Borislav Petkov (AMD) <bp@...en8.de>
I'll take it through tip if no one objects...
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists