| 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
| ||
|
Message-ID: <CAJZ5v0j++NyxtT6KKFUbMhenrQU1g8wLirgz+RC2wvHgHk7qjg@mail.gmail.com>
Date: Mon, 4 Nov 2024 22:42:54 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Ivan Shapovalov <intelfx@...elfx.name>
Cc: Mario Limonciello <superm1@...nel.org>, "Rafael J. Wysocki" <rafael@...nel.org>,
Borislav Petkov <bp@...en8.de>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>, "H . Peter Anvin" <hpa@...or.com>, Len Brown <lenb@...nel.org>,
Peter Zijlstra <peterz@...radead.org>, Mario Limonciello <mario.limonciello@....com>,
"Gautham R . Shenoy" <gautham.shenoy@....com>,
"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <linux-kernel@...r.kernel.org>,
"open list:ACPI" <linux-acpi@...r.kernel.org>, Oleksandr Natalenko <oleksandr@...alenko.name>
Subject: Re: [PATCH v3] ACPI: processor: Move arch_init_invariance_cppc() call later
On Mon, Nov 4, 2024 at 10:38 PM Ivan Shapovalov <intelfx@...elfx.name> wrote:
>
> On 2024-11-04 at 15:14 -0600, Mario Limonciello wrote:
> > On 11/4/2024 15:10, Rafael J. Wysocki wrote:
> > > On Mon, Nov 4, 2024 at 9:54 PM Mario Limonciello <superm1@...nel.org> wrote:
> > > >
> > > > From: Mario Limonciello <mario.limonciello@....com>
> > > >
> > > > arch_init_invariance_cppc() is called at the end of
> > > > acpi_cppc_processor_probe() in order to configure frequency invariance
> > > > based upon the values from _CPC.
> > > >
> > > > This however doesn't work on AMD CPPC shared memory designs that have
> > > > AMD preferred cores enabled because _CPC needs to be analyzed from all
> > > > cores to judge if preferred cores are enabled.
> > > >
> > > > This issue manifests to users as a warning since commit 21fb59ab4b97
> > > > ("ACPI: CPPC: Adjust debug messages in amd_set_max_freq_ratio() to warn"):
> > > > ```
> > > > Could not retrieve highest performance (-19)
> > > > ```
> > > >
> > > > However the warning isn't the cause of this, it was actually
> > > > commit 279f838a61f9 ("x86/amd: Detect preferred cores in
> > > > amd_get_boost_ratio_numerator()") which exposed the issue.
> > > >
> > > > To fix this problem, change arch_init_invariance_cppc() into a new weak
> > > > symbol that is called at the end of acpi_processor_driver_init().
> > > > Each architecture that supports it can declare the symbol to override
> > > > the weak one.
> > > >
> > > > Fixes: 279f838a61f9 ("x86/amd: Detect preferred cores in amd_get_boost_ratio_numerator()")
> > > > Reported-by: Ivan Shapovalov <intelfx@...elfx.name>
> > > > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219431
> > > > Tested-by: Oleksandr Natalenko <oleksandr@...alenko.name>
> > > > Signed-off-by: Mario Limonciello <mario.limonciello@....com>
> > > > ---
> > > > v3:
> > > > * Weak symbol instead of macro to help riscv build failure
> > > > * Update commit message
> > > > * Add comment
> > > > ---
> > > > arch/arm64/include/asm/topology.h | 2 +-
> > > > arch/x86/include/asm/topology.h | 2 +-
> > > > drivers/acpi/cppc_acpi.c | 6 ------
> > > > drivers/acpi/processor_driver.c | 9 +++++++++
> > > > include/acpi/processor.h | 2 ++
> > > > 5 files changed, 13 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
> > > > index 5fc3af9f8f29b..8a1860877967e 100644
> > > > --- a/arch/arm64/include/asm/topology.h
> > > > +++ b/arch/arm64/include/asm/topology.h
> > > > @@ -27,7 +27,7 @@ void update_freq_counters_refs(void);
> > > > #define arch_scale_freq_ref topology_get_freq_ref
> > > >
> > > > #ifdef CONFIG_ACPI_CPPC_LIB
> > > > -#define arch_init_invariance_cppc topology_init_cpu_capacity_cppc
> > > > +#define acpi_processor_init_invariance_cppc topology_init_cpu_capacity_cppc
> > > > #endif
> > > >
> > > > /* Replace task scheduler's default cpu-invariant accounting */
> > > > diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
> > > > index aef70336d6247..0fb705524aeaa 100644
> > > > --- a/arch/x86/include/asm/topology.h
> > > > +++ b/arch/x86/include/asm/topology.h
> > > > @@ -307,7 +307,7 @@ extern void arch_scale_freq_tick(void);
> > > >
> > > > #ifdef CONFIG_ACPI_CPPC_LIB
> > > > void init_freq_invariance_cppc(void);
> > > > -#define arch_init_invariance_cppc init_freq_invariance_cppc
> > > > +#define acpi_processor_init_invariance_cppc init_freq_invariance_cppc
> > > > #endif
> > > >
> > > > #endif /* _ASM_X86_TOPOLOGY_H */
> > > > diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
> > > > index 1a40f0514eaa3..5c0cc7aae8726 100644
> > > > --- a/drivers/acpi/cppc_acpi.c
> > > > +++ b/drivers/acpi/cppc_acpi.c
> > > > @@ -671,10 +671,6 @@ static int pcc_data_alloc(int pcc_ss_id)
> > > > * )
> > > > */
> > > >
> > > > -#ifndef arch_init_invariance_cppc
> > > > -static inline void arch_init_invariance_cppc(void) { }
> > > > -#endif
> > > > -
> > > > /**
> > > > * acpi_cppc_processor_probe - Search for per CPU _CPC objects.
> > > > * @pr: Ptr to acpi_processor containing this CPU's logical ID.
> > > > @@ -905,8 +901,6 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr)
> > > > goto out_free;
> > > > }
> > > >
> > > > - arch_init_invariance_cppc();
> > > > -
> > > > kfree(output.pointer);
> > > > return 0;
> > > >
> > > > diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> > > > index cb52dd000b958..3b281bc1e73c3 100644
> > > > --- a/drivers/acpi/processor_driver.c
> > > > +++ b/drivers/acpi/processor_driver.c
> > > > @@ -237,6 +237,9 @@ static struct notifier_block acpi_processor_notifier_block = {
> > > > .notifier_call = acpi_processor_notifier,
> > > > };
> > > >
> > > > +void __weak acpi_processor_init_invariance_cppc(void)
> > > > +{ }
> > >
> > > Does this actually work if acpi_processor_init_invariance_cppc is a
> > > macro? How does the compiler know that it needs to use
> > > init_freq_invariance_cppc() instead of this?
> > >
> > > It would work if a __weak definition of init_freq_invariance_cppc() was present.
> >
> > I also wasn't sure, so I explicitly added some tracing in
> > init_freq_invariance_cppc() to make sure it got called and checked it
> > (GCC 13.2.0).
>
> Aren't C macros substituted strictly lexically, i.e. if the #define is
> present by the time the function definition is parsed, it's just
>
> void __weak acpi_processor_init_invariance_cppc(void) {}
> -> void __weak init_freq_invariance_cppc(void) {}
>
> ? So it _is_ a weak definition of init_freq_invariance_cppc().
Yes, you're right.
> >
> > But I'll admit it's a confusing behavior. If you think it's too
> > confusing I'll swap it around to just axe the macros.
>
> ...That said, it does look kinda confusing. Seems to be norm for that
> arch/ header file though.
So let's not make it even more confusing than it already is.
Powered by blists - more mailing lists