linux-kernel - Re: [PATCH 1/5] cpuidle: Remove pointless stub

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:   Thu, 5 Nov 2020 15:14:23 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Lina Iyer <ilina@...eaurora.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH 1/5] cpuidle: Remove pointless stub

On Fri, Oct 16, 2020 at 10:31 PM Daniel Lezcano
<daniel.lezcano@...aro.org> wrote:
>
>
> Hi Rafael,
>
> On 16/10/2020 17:24, Rafael J. Wysocki wrote:
> > On Thu, Oct 15, 2020 at 4:44 PM Daniel Lezcano
> > <daniel.lezcano@...aro.org> wrote:
> >>
> >> The cpuidle.h header is declaring functions with an empty stub when
> >> cpuidle is not enabled. However these functions are only called from
> >> the governors which depends on cpuidle. In other words, when the
> >> function is called it is when cpuidle is enabled, there is no
> >> situation when it is called with cpuidle disabled.
> >>
> >> Remove the pointless stub.
> >>
> >> Signed-off-by: Daniel Lezcano <daniel.lezcano@...aro.org>
> >> ---
>
> [ ... ]
>
> > Applied (this patch alone) as 5.10-rc material with some minor edits
> > in the changelog, thanks!
>
> Does it mean you disagree the other patches? Or are you waiting for more
> comments?

Actually, both.

My primary concern regarding the modularization of cpuidle governors
is that they really belong to the core kernel.  They access the
internals thereof and the behavior of the idle loop in general depends
on what they do.

OTOH IMV a potential benefit resulting from allowing them to be
modular is very small, at least from the mainline perspective.

IOW this case is very similar to the modularization of the schedutil
cpufreq governor which we decided not to do for similar reasons.