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
| ||
|
Date: Wed, 30 Mar 2011 22:25:36 -0400 (EDT) From: Len Brown <lenb@...nel.org> To: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> Cc: Trinabh Gupta <trinabh@...ux.vnet.ibm.com>, venki@...gle.com, ak@...ux.intel.com, suresh.b.siddha@...el.com, sfr@...b.auug.org.au, peterz@...radead.org, benh@...nel.crashing.org, linux-kernel@...r.kernel.org, xen-devel@...ts.xensource.com, arjan@...ux.intel.com Subject: Re: [Xen-devel] Re: [RFC PATCH V4 2/5] cpuidle: list based cpuidle driver registration and selection thanks, Len Brown, Intel Open Source Technology Center On Fri, 25 Mar 2011, Konrad Rzeszutek Wilk wrote: > On Fri, Mar 25, 2011 at 03:05:36AM -0400, Len Brown wrote: > > > I think there are other problems too, related to saving and restoring > > > of pm_idle pointer. For example, cpuidle itself saves current value > > > of pm_idle, flips it and then restores the saved value. There is > > > no guarantee that the saved function still exists. APM does exact > > > same thing (though it may not be used these days). > > > > > > The problem also is that a number of architectures have copied the > > > same design based on pm_idle; so its spreading. > > > > pm_idle is a primitive design yes, but I think the issue > > with pm_idle is a theoretical one, at least on x86; > > as there isn't any other code scribbling on pm_idle > > in practice. So this is clean-up, rather than bug-fix work... > > > > > > It isn't immediately clear to me that all of these options > > > > need to be preserved. > > > > > > So what do you suggest can be removed? > > > > I sent a series of small patches yesterday to get the ball rolling... > > https://lkml.org/lkml/2011/3/24/54 > > > > I think the xen thing can go away. > > The xen thing being the setting of cpuidle to halt or the proposed > patch? I don't think Xen needs a cpuidle driver. Xen just needs to tell the kernel to call HALT, and I think we'll keep that around for the non-cpuidle case, and for the idle periods before cpuidle initializes. cheers, Len Brown, Intel Open Source Technology Center -- 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/
Powered by blists - more mailing lists