2021-06-04 17:08:59

by Kyle Meyer

[permalink] [raw]
Subject: [PATCH] acpi-cpufreq: Skip cleanup if initialization didn't occur

From: Kyle Meyer <[email protected]>

acpi-cpufreq is loaded without performing initialization when a cpufreq
driver exists.

If initialization didn't occur then skip cleanup in acpi_cpufreq_exit().
This prevents unnecessary freeing and unregistering when the module is
unloaded.

Reported-by: Takashi Iwai <[email protected]>
Signed-off-by: Kyle Meyer <[email protected]>
---
drivers/cpufreq/acpi-cpufreq.c | 11 +++++++++++
1 file changed, 11 insertions(+)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 7e7450453714..8d425f14c267 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -1042,8 +1042,19 @@ static int __init acpi_cpufreq_init(void)

static void __exit acpi_cpufreq_exit(void)
{
+ const char *current_driver;
+
pr_debug("%s\n", __func__);

+ /*
+ * If another cpufreq_driver was loaded, preventing acpi-cpufreq from
+ * registering, there's no need to unregister it.
+ */
+ current_driver = cpufreq_get_current_driver();
+ if (!current_driver ||
+ strncmp(current_driver, acpi_cpufreq_driver.name, strlen(acpi_cpufreq_driver.name)))
+ return;
+
acpi_cpufreq_boost_exit();

cpufreq_unregister_driver(&acpi_cpufreq_driver);
--
2.25.1


2021-06-07 03:29:41

by Viresh Kumar

[permalink] [raw]
Subject: Re: [PATCH] acpi-cpufreq: Skip cleanup if initialization didn't occur

On 04-06-21, 12:05, [email protected] wrote:
> From: Kyle Meyer <[email protected]>
>
> acpi-cpufreq is loaded without performing initialization when a cpufreq
> driver exists.
>
> If initialization didn't occur then skip cleanup in acpi_cpufreq_exit().
> This prevents unnecessary freeing and unregistering when the module is
> unloaded.
>
> Reported-by: Takashi Iwai <[email protected]>
> Signed-off-by: Kyle Meyer <[email protected]>
> ---
> drivers/cpufreq/acpi-cpufreq.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> index 7e7450453714..8d425f14c267 100644
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -1042,8 +1042,19 @@ static int __init acpi_cpufreq_init(void)
>
> static void __exit acpi_cpufreq_exit(void)
> {
> + const char *current_driver;
> +
> pr_debug("%s\n", __func__);
>
> + /*
> + * If another cpufreq_driver was loaded, preventing acpi-cpufreq from
> + * registering, there's no need to unregister it.
> + */
> + current_driver = cpufreq_get_current_driver();
> + if (!current_driver ||
> + strncmp(current_driver, acpi_cpufreq_driver.name, strlen(acpi_cpufreq_driver.name)))
> + return;
> +
> acpi_cpufreq_boost_exit();
>
> cpufreq_unregister_driver(&acpi_cpufreq_driver);

Looks like some misunderstanding here, this shouldn't happen. If
initialization didn't occur, then exit shall never be called.

--
viresh

2021-06-07 07:16:01

by Takashi Iwai

[permalink] [raw]
Subject: Re: [PATCH] acpi-cpufreq: Skip cleanup if initialization didn't occur

On Mon, 07 Jun 2021 05:25:50 +0200,
Viresh Kumar wrote:
>
> On 04-06-21, 12:05, [email protected] wrote:
> > From: Kyle Meyer <[email protected]>
> >
> > acpi-cpufreq is loaded without performing initialization when a cpufreq
> > driver exists.
> >
> > If initialization didn't occur then skip cleanup in acpi_cpufreq_exit().
> > This prevents unnecessary freeing and unregistering when the module is
> > unloaded.
> >
> > Reported-by: Takashi Iwai <[email protected]>
> > Signed-off-by: Kyle Meyer <[email protected]>
> > ---
> > drivers/cpufreq/acpi-cpufreq.c | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> > index 7e7450453714..8d425f14c267 100644
> > --- a/drivers/cpufreq/acpi-cpufreq.c
> > +++ b/drivers/cpufreq/acpi-cpufreq.c
> > @@ -1042,8 +1042,19 @@ static int __init acpi_cpufreq_init(void)
> >
> > static void __exit acpi_cpufreq_exit(void)
> > {
> > + const char *current_driver;
> > +
> > pr_debug("%s\n", __func__);
> >
> > + /*
> > + * If another cpufreq_driver was loaded, preventing acpi-cpufreq from
> > + * registering, there's no need to unregister it.
> > + */
> > + current_driver = cpufreq_get_current_driver();
> > + if (!current_driver ||
> > + strncmp(current_driver, acpi_cpufreq_driver.name, strlen(acpi_cpufreq_driver.name)))
> > + return;
> > +
> > acpi_cpufreq_boost_exit();
> >
> > cpufreq_unregister_driver(&acpi_cpufreq_driver);
>
> Looks like some misunderstanding here, this shouldn't happen. If
> initialization didn't occur, then exit shall never be called.

The missing key information is that it's a fix for the recent change
for 5.14, i.e.
Fixes: c1d6d2fd2f64 ("cpufreq: acpi-cpufreq: Skip initialization if cpufreq driver is present")

The change made the module left even if it exits before registering
the cpufreq driver object.


Takashi

2021-06-07 07:31:04

by Viresh Kumar

[permalink] [raw]
Subject: Re: [PATCH] acpi-cpufreq: Skip cleanup if initialization didn't occur

On 07-06-21, 09:13, Takashi Iwai wrote:
> The missing key information is that it's a fix for the recent change
> for 5.14, i.e.
> Fixes: c1d6d2fd2f64 ("cpufreq: acpi-cpufreq: Skip initialization if cpufreq driver is present")
>
> The change made the module left even if it exits before registering
> the cpufreq driver object.

The original patch looks buggy to me, I was never able to review it :(

I have replied on the original thread instead.

--
viresh

2021-06-07 11:14:13

by Rafael J. Wysocki

[permalink] [raw]
Subject: Re: [PATCH] acpi-cpufreq: Skip cleanup if initialization didn't occur

On Mon, Jun 7, 2021 at 9:26 AM Viresh Kumar <[email protected]> wrote:
>
> On 07-06-21, 09:13, Takashi Iwai wrote:
> > The missing key information is that it's a fix for the recent change
> > for 5.14, i.e.
> > Fixes: c1d6d2fd2f64 ("cpufreq: acpi-cpufreq: Skip initialization if cpufreq driver is present")
> >
> > The change made the module left even if it exits before registering
> > the cpufreq driver object.
>
> The original patch looks buggy to me, I was never able to review it :(
>
> I have replied on the original thread instead.

Well, thanks, but that confused me a bit.

Given the above, I'm going to drop the original patch.

Kyle, please reconsider this approach.