linux-kernel - Re: [PATCH 4/6] x86/cpufreq: use cpumask

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: <20090610170158.GB31096@elte.hu>
Date:	Wed, 10 Jun 2009 19:01:58 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Dave Jones <davej@...hat.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Yinghai Lu <yinghai@...nel.org>, Avi Kivity <avi@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	cpufreq@...r.kernel.org
Subject: Re: [PATCH 4/6] x86/cpufreq: use cpumask_copy instead of =


* Dave Jones <davej@...hat.com> wrote:

> On Wed, Jun 10, 2009 at 01:50:22PM +0930, Rusty Russell wrote:
>  > On Tue, 9 Jun 2009 05:43:27 pm Yinghai Lu wrote:
>  > > Rusty Russell wrote:
>  > > > On Sun, 7 Jun 2009 07:23:52 am Yinghai Lu wrote:
>  > > >> so later could use nr_cpumask_bits in cpumask_size when MAXSMP is used
>  > > >
>  > > > I have a (more ambitious) patch for this in my queue, which weans it off
>  > > > this entirely:
>  > > >
>  > > > Subject: cpumask: avoid playing with cpus_allowed in powernow-k8.c
>  > ...
>  > > will be in .31?
>  > 
>  > Hope so, it's been in linux-next for ages.  The cpufreq 
>  > maintainers seem to take a relaxed approach to patches, FWIW.
> 
> With so much of the cpumask stuff going through Ingo's trees, I've 
> taken the approach that it's easier to just let it continue to do 
> so rather than cherry picking the occasional cpufreq touching 
> part.

Well, now that the main (and most risky) cpumask changes are over 
and done, it would be nice to go back to the regular model. Overlap 
in trees frequently causes bugs, friction and general unhappiness. 
There's nothing cpufreq related pending in any of the -tip trees in 
this cycle.

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