linux-kernel - Re: [PATCH 2/2] opp: quiet down WARN when no valid OPPs remain

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: <20200108064901.rf6r7buy6tcxsrzc@vireshk-i7>
Date:   Wed, 8 Jan 2020 12:19:01 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Michał Mirosław <mirq-linux@...e.qmqm.pl>
Cc:     Nishanth Menon <nm@...com>, Stephen Boyd <sboyd@...nel.org>,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] opp: quiet down WARN when no valid OPPs remain

On 07-01-20, 14:57, Michał Mirosław wrote:
> On Tue, Jan 07, 2020 at 05:00:55PM +0530, Viresh Kumar wrote:
> > On 07-01-20, 10:58, Michał Mirosław wrote:
> > > On Tue, Jan 07, 2020 at 12:11:29PM +0530, Viresh Kumar wrote:
> > > > On 03-01-20, 20:36, Michał Mirosław wrote:
> > > > > Per CPU screenful of backtraces is not really that useful. Replace
> > > > > WARN with a diagnostic discriminating common causes of empty OPP table.
> > > > But why should a platform have an OPP table in DT where none of them works for
> > > > it ? I added the warn intentionally here just for that case.
> > > Hmm. I guess we can make it WARN_ON_ONCE instead of removing it
> > I am not sure this will get triggered more than once normally anyway, isn't it ?
> 
> It is triggered once per core.

What platform it is ? Maybe because cpufreq driver failed to initialize the
policy for all CPUs and so this is getting repeated.

> > > , but I
> > > don't think the backtrace is ever useful in this case.
> > Hmm, I am less concerned about backtraces than highlighting problem in a serious
> > way. The simple print messages are missed many times by people and probably
> > that's why I used a WARN instead.
> 
> > 
> > > Empty table can
> > > be because eg. you run old DT on newer hardware version.
> > 
> > Hmm, but then a big warning isn't that bad as we need to highlight the issue to
> > everyone as cpufreq won't be working. isn't it ?
> 
> A user normally can't do much about it. Rather this is a developer targeted
> message. Maybe a rewording of the messages be better? Something to also
> include consequences of the error?

I agree that a WARN may be a bit excessive here.

-- 
viresh