linux-kernel - Re: [PATCH V2] cpufreq: Make sure CPU is running on a freq from freq-table

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:	Tue, 26 Nov 2013 07:31:50 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Dirk Brandewie <dirk.brandewie@...il.com>,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
	Patch Tracking <patches@...aro.org>,
	"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Nishanth Menon <nm@...com>, Carlos Hernandez <ceh@...com>
Subject: Re: [PATCH V2] cpufreq: Make sure CPU is running on a freq from freq-table

On 26 November 2013 02:43, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> On Monday, November 25, 2013 09:43:59 AM Dirk Brandewie wrote:
>> This is a platform specific bug fix AFAICT and belongs in a platform
>> specific piece of code

In case we end up doing that, we will do lots of code redundancy in
cpufreq drivers. And as Rafael said, some platforms might never
know they have booted with an out of table frequency and so taking
care of this at a single place is better, where we are sure that it
will get fixed.

>> The core should not be working around bootloader bugs IMHO.  Silently
>> fixing it is evil IMHO at a minimum the core should complain LOUDLY
>> about this happening otherwise the bootloaders will have no incentive to
>> get their act together.

That looks correct..

> Yes, we can add a WARN_ON() there.  Still, though, the core's responsibility
> is to ensure that (a) either we can continue safely or (b) we can't, in which
> case it should just fail the initialization.  Whether or not it should panic()
> I'm not sure.

But is this that big crime, that we do a WARN on it? CPU was running on
a workable frequency, it wasn't mentioned in the table, that's it.

Probably just throw an print message that CPU found to be running on
out of table frequency, and that got fixed..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/