linux-kernel - Re: [PATCH v2 2/3] sched: Cleanup SCHED_THERMAL

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]

Date:   Wed, 29 Jul 2020 10:07:21 +0200
From:   Dietmar Eggemann <dietmar.eggemann@....com>
To:     Valentin Schneider <valentin.schneider@....com>
Cc:     Qian Cai <cai@....pw>, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-pm@...r.kernel.org,
        Russell King <linux@...linux.org.uk>,
        Thara Gopinath <thara.gopinath@...aro.org>,
        Sudeep Holla <sudeep.holla@....com>,
        Amit Daniel Kachhap <amit.kachhap@...il.com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [PATCH v2 2/3] sched: Cleanup SCHED_THERMAL_PRESSURE kconfig
 entry

On 28/07/2020 18:16, Valentin Schneider wrote:
> 
> Hi,
> 
> On 27/07/20 18:45, Dietmar Eggemann wrote:
>> On 27/07/2020 16:18, Qian Cai wrote:
>>> On Sun, Jul 12, 2020 at 05:59:16PM +0100, Valentin Schneider wrote:

[...]

> I went for having SCHED_THERMAL_PRESSURE in arm64/Kconfig because of where
> the discussion went in the original thread ([1] in the changelog).
> 
> One point is that selecting this option requires having the right
> infrastructure in place (arch_{set, scale}_thermal_pressure() must be
> redefined by the architecture), which cannot be easily expressed in Kconfig
> terms. Russell's point was that this is difficult for a lambda user to make
> sense of, and Vincent argued that this option should simply be selected at
> architecture level, which, given the context, makes sense IMO.
> 
> We could change the arch Kconfig into
> 
>   select SCHED_THERMAL_PRESSURE if CPU_FREQ_THERMAL
> 
> but that seems redundant; this dependency is already expressed in
> SCHED_THERMAL_PRESSURE's definition. Is there a proper pattern to select
> some Kconfig option only if all of its dependencies are met?

The warning when disabling CPU_FREQ_THERMAL after make defconfig disappears, so
this should be OK.

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 939c4d6bbc2e..a677e71b3d5f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -46,7 +46,7 @@ config ARM
        select EDAC_ATOMIC_SCRUB
        select GENERIC_ALLOCATOR
        select GENERIC_ARCH_TOPOLOGY if ARM_CPU_TOPOLOGY
-       select SCHED_THERMAL_PRESSURE if ARM_CPU_TOPOLOGY
+       select SCHED_THERMAL_PRESSURE if ARM_CPU_TOPOLOGY && CPU_FREQ_THERMAL
        select GENERIC_ATOMIC64 if CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI
        select GENERIC_CLOCKEVENTS_BROADCAST if SMP
        select GENERIC_CPU_AUTOPROBE
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index c403e6f5db86..59ae16f8b941 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -192,7 +192,7 @@ config ARM64
        select PCI_SYSCALL if PCI
        select POWER_RESET
        select POWER_SUPPLY
-       select SCHED_THERMAL_PRESSURE
+       select SCHED_THERMAL_PRESSURE if CPU_FREQ_THERMAL
        select SPARSE_IRQ
        select SWIOTLB
        select SYSCTL_EXCEPTION_TRAC