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: <20200107135743.GA20159@qmqm.qmqm.pl>
Date:   Tue, 7 Jan 2020 14:57:43 +0100
From:   Michał Mirosław <mirq-linux@...e.qmqm.pl>
To:     Viresh Kumar <viresh.kumar@...aro.org>
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 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.

> > , 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?

Best Regards,
Michał Mirosław