linux-kernel - Re: [PATCH v2] cpufreq: fix compile-test defaults

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: <aACxzWi4KqDdylfj@hovoldconsulting.com>
Date: Thu, 17 Apr 2025 09:46:21 +0200
From: Johan Hovold <johan@...nel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Johan Hovold <johan+linaro@...nel.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	"Rob Herring (Arm)" <robh@...nel.org>, linux-pm@...r.kernel.org,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v2] cpufreq: fix compile-test defaults

On Thu, Apr 17, 2025 at 09:28:43AM +0200, Krzysztof Kozlowski wrote:
> On 17/04/2025 09:22, Johan Hovold wrote:

> >>> Fix the default values for drivers that can be compile tested and that
> >>> should be enabled by default when not compile testing.
> >>>
> >>> Fixes: 3f66425a4fc8 ("cpufreq: Enable COMPILE_TEST on Arm drivers")
> >>
> >>
> >>> Fixes: d4f610a9bafd ("cpufreq: Do not enable by default during compile testing")
> >>
> >> That's not correct tag - it introduced no new issues, did not make
> >> things worse, so nothing to fix there, if I understand correctly.
> > 
> > Fair enough, I could have used dependency notation for this one.
> > 
> > Let me do that in v3.
> 
> OK. I have doubts that this should be marked as a fix in the first place
> - even skipping my commit. Some (several?) people were always
> considering COMPILE_TEST as enable everything, thus for them this was
> the intention, even if it causes such S3C64xx cpufreq warnings:
> 
> https://lore.kernel.org/all/8b6ede05-281a-4fb1-bcdc-457e6f2610ff@roeck-us.net/

Sounds like you, me and Arnd and least have the same understanding of
how COMPILE_TEST should work.

I use it all the time when fixing issues that have been reproduced in
several drivers which I then enable manually. And I usually keep them
enabled in my development kernels for a while after in case something
needs to be reworked.

If you want to compile everything as well you should do an allmodconfig
build.

> I had also talks about this in the past that one should never boot
> compile test kernel.

I have never noticed any issues with that until the other day with the
cpufreq driver, but yeah, I can imagine that other "default y" entries
could potentially cause issues.

Johan