From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>,
<linuxarm@huawei.com>, <rafael.j.wysocki@intel.com>,
<guohanjun@huawei.com>, <gshan@redhat.com>,
<miguel.luis@oracle.com>, <catalin.marinas@arm.com>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
Linux regressions mailing list <regressions@lists.linux.dev>,
Ingo Molnar <mingo@redhat.com>, "Borislav Petkov" <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>, <x86@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
"Bowman, Terry" <Terry.bowman@amd.com>,
Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
Subject: Re: 6.11/regression/bisected - The commit c1385c1f0ba3 caused a new possible recursive locking detected warning at computer boot.
Date: Fri, 26 Jul 2024 18:14:24 +0100 [thread overview]
Message-ID: <20240726181424.000039a4@Huawei.com> (raw)
In-Reply-To: <87le1ounl2.ffs@tglx>
On Fri, 26 Jul 2024 18:26:01 +0200
Thomas Gleixner <tglx@linutronix.de> wrote:
> On Thu, Jul 25 2024 at 18:13, Jonathan Cameron wrote:
> > On Tue, 23 Jul 2024 18:20:06 +0100
> > Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:
> >
> >> > This is an interesting corner and perhaps reflects a flawed
> >> > assumption we were making that for this path anything that can happen for an
> >> > initially present CPU can also happen for a hotplugged one. On the hotplugged
> >> > path the lock was always held and hence the static_key_enable() would
> >> > have failed.
>
> No. The original code invoked this without cpus read locked via:
>
> acpi_processor_driver.probe()
> __acpi_processor_start()
> ....
>
> and the cpu hotplug callback finds it already set up, so it won't reach
> the static_key_enable() anymore.
>
> > One bit I need to check out tomorrow is to make sure this doesn't race with the
> > workfn that is used to tear down the same static key on error.
>
> There is a simpler solution for that. See the uncompiled below.
Thanks. FWIW I got pretty much the same suggestion from Shameer this
morning when he saw the workfn solution on list. Classic case of me
missing the simple solution because I was down in the weeds.
I'm absolutely fine with this fix.
Mikhail, please could you test Thomas' proposal so we are absolutely sure
nothing else is hiding.
Tglx's solution is much less likely to cause problems than what I proposed because
it avoids changing the ordering.
Jonathan
>
> Thanks,
>
> tglx
> ---
> diff --git a/arch/x86/kernel/cpu/aperfmperf.c b/arch/x86/kernel/cpu/aperfmperf.c
> index b3fa61d45352..0b69bfbf345d 100644
> --- a/arch/x86/kernel/cpu/aperfmperf.c
> +++ b/arch/x86/kernel/cpu/aperfmperf.c
> @@ -306,7 +306,7 @@ static void freq_invariance_enable(void)
> WARN_ON_ONCE(1);
> return;
> }
> - static_branch_enable(&arch_scale_freq_key);
> + static_branch_enable_cpuslocked(&arch_scale_freq_key);
> register_freq_invariance_syscore_ops();
> pr_info("Estimated ratio of average max frequency by base frequency (times 1024): %llu\n", arch_max_freq_ratio);
> }
> @@ -323,8 +323,10 @@ static void __init bp_init_freq_invariance(void)
> if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
> return;
>
> - if (intel_set_max_freq_ratio())
> + if (intel_set_max_freq_ratio()) {
> + guard(cpus_read_lock)();
> freq_invariance_enable();
> + }
> }
>
> static void disable_freq_invariance_workfn(struct work_struct *work)
>
>
next prev parent reply other threads:[~2024-07-26 17:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-22 19:36 6.11/regression/bisected - The commit c1385c1f0ba3 caused a new possible recursive locking detected warning at computer boot Mikhail Gavrilov
2024-07-23 10:24 ` Jonathan Cameron
2024-07-23 17:20 ` Jonathan Cameron
2024-07-25 17:13 ` Jonathan Cameron
2024-07-25 22:30 ` Mikhail Gavrilov
2024-07-26 15:07 ` Terry Bowman
2024-07-26 16:37 ` Jonathan Cameron
2024-07-26 17:59 ` Jonathan Cameron
2024-07-26 16:26 ` Thomas Gleixner
2024-07-26 17:14 ` Jonathan Cameron [this message]
2024-07-26 18:01 ` Jonathan Cameron
2024-07-26 20:35 ` Thomas Gleixner
2024-07-27 7:13 ` Mikhail Gavrilov
2024-08-03 15:48 ` Hans de Goede
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=20240726181424.000039a4@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=Terry.bowman@amd.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=gshan@redhat.com \
--cc=guohanjun@huawei.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=miguel.luis@oracle.com \
--cc=mikhail.v.gavrilov@gmail.com \
--cc=mingo@redhat.com \
--cc=rafael.j.wysocki@intel.com \
--cc=regressions@lists.linux.dev \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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