linux-kernel - Re: [linux-pm] [PATCH 0/3] coupled cpuidle state support

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:	Thu, 22 Dec 2011 15:00:34 +0530
From:	"Shilimkar, Santosh" <santosh.shilimkar@...com>
To:	Arjan van de Ven <arjan@...ux.intel.com>
Cc:	Colin Cross <ccross@...roid.com>, Kevin Hilman <khilman@...com>,
	Len Brown <len.brown@...el.com>, linux-kernel@...r.kernel.org,
	Amit Kucheria <amit.kucheria@...aro.org>,
	linux-tegra@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [linux-pm] [PATCH 0/3] coupled cpuidle state support

On Thu, Dec 22, 2011 at 2:23 PM, Arjan van de Ven <arjan@...ux.intel.com> wrote:
> On 12/22/2011 9:35 AM, Shilimkar, Santosh wrote:
>
>> Indeed. The SOCs, Arch's which does support low power
>> state independently and doesn't need any co-ordination between CPU's
>> will continue to work same way as before with this series.
>
> btw I think you misunderstand; I don't object to a need for something
> like this,
I did. Thanks for clarification.

> I am just very concerned that this may not be possible to be
> done in a race-free way.
>
I agree to those races but may be they are harmless.
Also the safe state need not be just WFI and can be bit deeper
where the co-ordination between isn't necessary. So that should
still not burn the power that much.

For simplicity let's assume a two CPU scenario.
Ideal scenario:
CPU 1 has entered idle and incremented counter for the
co-ordinated C state. CPU0 also enter and increments the
counter and now the subsystem and interconnect can go
down along with CPU cluster.

Few of the race conditions will possibly lead to void
the above conditions  and in that case the counter would
reflect that and such a C-state won't be attempted and
a safe C-state would be attempted. That should still work
fine.

Some how this hardware/security restriction is bit stupid
and likely going against the existing CPUIDLE design
which expect that a CPUIDLE thread are per CPU and it should
be independent and local to that CPU.

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