linux-kernel - Re: [PATCH V6 Resend 1/5] cpufreq: suspend governors on system suspend/hibernate

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: <CAKohpokRTb=o7xR5y9TLZ8YvSzkMC-37YxuSoUyES-oEOwM-jQ@mail.gmail.com>
Date:	Wed, 5 Mar 2014 09:49:10 +0800
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Lists linaro-kernel <linaro-kernel@...ts.linaro.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>,
	Stephen Warren <swarren@...dotorg.org>,
	Kgene Kim <kgene.kim@...sung.com>,
	"jinchoi@...adcom.com" <jinchoi@...adcom.com>,
	Lan Tianyu <tianyu.lan@...el.com>,
	Sebastian Capella <sebastian.capella@...aro.org>,
	Jonghwan Choi <jhbird.choi@...sung.com>
Subject: Re: [PATCH V6 Resend 1/5] cpufreq: suspend governors on system suspend/hibernate

On 5 March 2014 08:37, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> So, previously the driver's ->suspend callback was executed with interrupts off
> and it was only executed for the boot CPU.
>
> Now, it is going to be executed for all CPUs and with interrupts on.

Its not called for all CPUs but once for each instance of 'policy'.

> This sounds potentially dangerous, so did you check all drivers supplying
> ->suspend if they are fine with that?
>
> And same for ->resume, of course.

Completely agree with you on that. I had similar doubts when I started earlier.
And then grep'd for suspend/resume in drivers/cpufreq and this is what I found:

drivers/cpufreq/acpi-cpufreq.c: Only have resume implemented and is unaffected
with new code.

drivers/cpufreq/pmac32-cpufreq.c: This is always UP and so no issues.

drivers/cpufreq/s3c24xx-cpufreq.c: There is only one policy and so would be
called only once.

drivers/cpufreq/speedstep-smi.c: Only has resume implemented and it looks
to be harmless again..

So, I think yes, we shouldn't end up breaking any stuff here. Fingers crossed :)
Otherwise as well, I am not going on leaves or something else in coming weeks
and would be there to fix any issues that might come in. But I am
still hopeful of
not breaking any existing stuff.
--
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/