linux-kernel - Re: [PATCH] ACPI: cpufreq: Prevent a warning when another frequency driver is loaded

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

Message-ID: <ZGDfP6e/Ubgt49YN@kevinlocke.name>
Date:   Sun, 14 May 2023 07:16:47 -0600
From:   Kevin Locke <kevin@...inlocke.name>
To:     Petr Pavlu <petr.pavlu@...e.com>
Cc:     rafael@...nel.org, viresh.kumar@...aro.org,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ACPI: cpufreq: Prevent a warning when another frequency
 driver is loaded

On Thu, 2023-05-11 at 14:53 +0200, Petr Pavlu wrote:
> Address it by changing the return code in acpi-cpufreq and pcc-cpufreq
> for this case from -EEXIST to -ENODEV which silences the warning in
> call_driver_probe().
> 
> The change has also a benefit for users of init_module() as this return
> code is propagated out from the syscall. The previous -EEXIST code made
> the callers, such as kmod, wrongly believe that the module was already
> loaded instead of that it failed to load.

Thanks for addressing this issue so quickly!

I can confirm that with this patch applied I no longer receive
kernel: acpi-cpufreq: probe of acpi-cpufreq failed with error -17
at boot.  Additionally, modprobe acpi-cpufreq now produces
modprobe: ERROR: could not insert 'acpi_cpufreq': No such device
rather than silently failing (without --first-time) to load the
module as it did before, which seems good to me.

Tested-by: Kevin Locke <kevin@...inlocke.name>

Cheers,
Kevin