linux-kernel - Re: 2.6.31-rc2+: Interrupts enabled after cpufreq

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] [day] [month] [year] [list]

Date:	Thu, 16 Jul 2009 13:10:47 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Dave Jones <davej@...hat.com>
Cc:	Marcin Slusarz <marcin.slusarz@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux PM List <linux-pm@...ts.linux-foundation.org>,
	cpufreq@...r.kernel.org
Subject: Re: 2.6.31-rc2+: Interrupts enabled after cpufreq_suspend

On Fri, 2009-07-10 at 19:46 -0400, Dave Jones wrote:

> The fail part comes from the fact that interrupts get reenabled.
> And that's something that can easily happen out of our control if
> we call into acpi_cpufreq's ->get method for example, so powernow-k8 isn't
> the sole reason.
> 
>  > I'm happy instead of #ifdef's however to push the logic into the ppc
>  > driver, or use a flag that the ppc driver sets to enable that logic.

So I'm not too familiar with what other platforms expect here, but would
it be ok to do something like bailing our early in cpufreq_suspend() if
there's no cpufreq_driver->suspend method ?

We would need to do the same on resume, though I do wonder whether there
could be a problem with even x86 here.. do we know for sure that we come
back from suspend with the same policy we had before suspending ? IE. We
should probably always do that check on resume, but we can't do it too
early due to irqs being off...

It's all because cpufreq is a sysdev which was imho a mistake in the
first place :-)

Maybe at this stage the best option is to add suspend_prepare and
resume_finish callbacks to sysdevs that are called while IRQs are still
on, and move cpufreq to use these instead ? That probably means we also
need to keep track that we have started suspend in the cpufreq core and
forbid attempts at changing policy etc... from either userspace of
on-demand governor while suspended, so that's more work, but could be
the best approach in the long run, what do you think ?

Otherwise I'm happy to just submit a patch that makes
cpufreq_suspend/resume bail out early if driver->suspend/resume are NULL
(or do you prefer a driver flag ?)

Cheers,
Ben.

--
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/