linux-next: manual merge of the rr tree

linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
kernel/stop_machine.c between commit
961ccddd59d627b89bd3dc284b6517833bbdf25d ("sched: add new API
sched_setscheduler_nocheck: add a flag to control access") from the sched
tree (which is also in the rr tree) and commit
179da75b083a098ba6192c0900611a92091abfc9 ("stop_machine:simplify") from
the rr tree.

I just took the rr tree version since the former is in both trees.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
drivers/char/hvc_console.h between commit
1c8950ff87de950a3b6ccfb26650fc0a56278836 ("[POWERPC] Make cpus_in_xmon
static and remove extern mess from hvc_console.c") from the powerpc tree
and commit c9a834016cfb2b0fb71392fddab4d80ab9f9d172 ("hvc_console: rework
setup to replace irq functions with callbacks") from the rr tree.

Just a matter of overlapping additions.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: manual merge of the rr tree

[Christian Borntraeger]

Am Mittwoch, 25. Juni 2008 schrieb Stephen Rothwell:
> Hi Rusty,
> 
> Today's linux-next merge of the rr tree got a conflict in
> drivers/char/hvc_console.h between commit
> 1c8950ff87de950a3b6ccfb26650fc0a56278836 ("[POWERPC] Make cpus_in_xmon
> static and remove extern mess from hvc_console.c") from the powerpc tree
> and commit c9a834016cfb2b0fb71392fddab4d80ab9f9d172 ("hvc_console: rework
> setup to replace irq functions with callbacks") from the rr tree.
> 
> Just a matter of overlapping additions.

Yes, it looks simple. What is the preferred way of solving such conflicts in 
linux-next?

Re: linux-next: manual merge of the rr tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Rusty,
> 
> Today's linux-next merge of the rr tree got a conflict in 
> kernel/stop_machine.c between commit 
> 961ccddd59d627b89bd3dc284b6517833bbdf25d ("sched: add new API 
> sched_setscheduler_nocheck: add a flag to control access") from the 
> sched tree (which is also in the rr tree) and commit 
> 179da75b083a098ba6192c0900611a92091abfc9 ("stop_machine:simplify") 
> from the rr tree.
> 
> I just took the rr tree version since the former is in both trees.

Rusty, there's a new -tip toy/feature i've applied when creating that 
commit 2 days ago, to eliminate this (predictable) conflict.

Since this is a scheduler infrastructure change, i've put this change 
into a separate topic branch in -tip:

   tip/sched/new-API-sched_setscheduler

This new topic branch is based off upstream -git so you can pick up that 
change alone via a single git-pull, without picking up any other 
scheduler changes. (any further enhancements to that change should be 
done in that topic branches as well)

This topic is integrated into tip/auto-sched-next, so any changes to the 
topic will be propagated into linux-next as well. I think this is the 
right model for doing infrastructure changes - separating them into 
standalone trees so that other subsystem maintainers can pull them when 
they run into conflicts.

Please use that commit and remove 179da75b083a09 so that there's no 
overlap in the sha1 space and no conflicts. -tip can be picked up via: 
http://people.redhat.com/mingo/tip.git/README .

Thanks,

	Ingo

Re: linux-next: manual merge of the rr tree

[Rusty Russell]

On Wednesday 25 June 2008 17:47:33 Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Rusty,
> >
> > Today's linux-next merge of the rr tree got a conflict in
> > kernel/stop_machine.c between commit
> > 961ccddd59d627b89bd3dc284b6517833bbdf25d ("sched: add new API
> > sched_setscheduler_nocheck: add a flag to control access") from the
> > sched tree (which is also in the rr tree) and commit
> > 179da75b083a098ba6192c0900611a92091abfc9 ("stop_machine:simplify")
> > from the rr tree.
> >
> > I just took the rr tree version since the former is in both trees.
>
> Rusty, there's a new -tip toy/feature i've applied when creating that
> commit 2 days ago, to eliminate this (predictable) conflict.
>
> Since this is a scheduler infrastructure change, i've put this change
> into a separate topic branch in -tip:
>
>    tip/sched/new-API-sched_setscheduler
>
> This new topic branch is based off upstream -git so you can pick up that
> change alone via a single git-pull, without picking up any other
> scheduler changes. (any further enhancements to that change should be
> done in that topic branches as well)
>
> This topic is integrated into tip/auto-sched-next, so any changes to the
> topic will be propagated into linux-next as well. I think this is the
> right model for doing infrastructure changes - separating them into
> standalone trees so that other subsystem maintainers can pull them when
> they run into conflicts.
>
> Please use that commit and remove 179da75b083a09 so that there's no
> overlap in the sha1 space and no conflicts. -tip can be picked up via:
> http://people.redhat.com/mingo/tip.git/README .

That would probably work, but I don't use git.

Stephen's already resolved it; AFAICT getting the exact same patch from two 
places is not a real problem for him anyway.

In this case, I'm tempted to just throw the stop_machine patch into your tree; 
that's the only reason I care about this change.  I haven't done that yet 
because I suspect that I broke hotplug CPU.

Cheers,
Rusty.

Re: linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

Hi Christian,

On Wed, 25 Jun 2008 08:38:40 +0200 Christian Borntraeger <borntraeger@de.ibm.com> wrote:
>
> Am Mittwoch, 25. Juni 2008 schrieb Stephen Rothwell:
> > Hi Rusty,
> > 
> > Today's linux-next merge of the rr tree got a conflict in
> > drivers/char/hvc_console.h between commit
> > 1c8950ff87de950a3b6ccfb26650fc0a56278836 ("[POWERPC] Make cpus_in_xmon
> > static and remove extern mess from hvc_console.c") from the powerpc tree
> > and commit c9a834016cfb2b0fb71392fddab4d80ab9f9d172 ("hvc_console: rework
> > setup to replace irq functions with callbacks") from the rr tree.
> > 
> > Just a matter of overlapping additions.
> 
> Yes, it looks simple. What is the preferred way of solving such conflicts in 
> linux-next?

I just carry them ("git rerere" make that easy).  These are the sort of
conflicts that Linus will just fix up when he merges these trees in his
tree.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
kernel/stop_machine.c between commit
961ccddd59d627b89bd3dc284b6517833bbdf25d ("sched: add new API
sched_setscheduler_nocheck: add a flag to control access checks") from
the sched tree (which appears to also be in the rr tree) and commit
e5e62fcd081b0837f6210eb4ed022e9d8920bc59 ("stop_machine:simplify") from
the rr tree.

I used the version in the rr tree.  Probably worth a look when I publish
the tree.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: manual merge of the rr tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Rusty,
> 
> Today's linux-next merge of the rr tree got a conflict in 
> kernel/stop_machine.c between commit 
> 961ccddd59d627b89bd3dc284b6517833bbdf25d ("sched: add new API 
> sched_setscheduler_nocheck: add a flag to control access checks") from 
> the sched tree (which appears to also be in the rr tree) and commit 
> e5e62fcd081b0837f6210eb4ed022e9d8920bc59 ("stop_machine:simplify") 
> from the rr tree.
> 
> I used the version in the rr tree.  Probably worth a look when I 
> publish the tree.

hm, is there any difference between the content of the two commits?

The "home tree" of the commit is tip/sched/new-API-sched_setscheduler, 
and that's integrated to the auto-sched-next branch. If there's any 
update to the patch we should iterate it there.

	Ingo

Re: linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]

Hi Ingo,

On Thu, 3 Jul 2008 07:56:45 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> > Today's linux-next merge of the rr tree got a conflict in 
> > kernel/stop_machine.c between commit 
> > 961ccddd59d627b89bd3dc284b6517833bbdf25d ("sched: add new API 
> > sched_setscheduler_nocheck: add a flag to control access checks") from 
> > the sched tree (which appears to also be in the rr tree) and commit 
> > e5e62fcd081b0837f6210eb4ed022e9d8920bc59 ("stop_machine:simplify") 
> > from the rr tree.
> > 
> > I used the version in the rr tree.  Probably worth a look when I 
> > publish the tree.
> 
> hm, is there any difference between the content of the two commits?

I checked after I sent the email and there is no difference.  The
conflict is caused by the further changes in Rusty's tree.

> The "home tree" of the commit is tip/sched/new-API-sched_setscheduler, 
> and that's integrated to the auto-sched-next branch. If there's any 
> update to the patch we should iterate it there.

That would be a question for Rusty.  He may be able to split out the
conflicting part of his simplification patch and send it to you.  But it
may not be worth it.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: manual merge of the rr tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> > The "home tree" of the commit is 
> > tip/sched/new-API-sched_setscheduler, and that's integrated to the 
> > auto-sched-next branch. If there's any update to the patch we should 
> > iterate it there.
> 
> That would be a question for Rusty.  He may be able to split out the 
> conflicting part of his simplification patch and send it to you.  But 
> it may not be worth it.

should be all OK as long as Rusty sends his patches to Linus after the 
-tip changes go upstream. (in that case the base patch will fall out of 
Rusty's Quilt queue naturally, leaving the followup change.)

	Ingo

Re: linux-next: manual merge of the rr tree

[Rusty Russell]

On Thursday 03 July 2008 15:56:45 Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Rusty,
> >
> > Today's linux-next merge of the rr tree got a conflict in
> > kernel/stop_machine.c between commit
> > 961ccddd59d627b89bd3dc284b6517833bbdf25d ("sched: add new API
> > sched_setscheduler_nocheck: add a flag to control access checks") from
> > the sched tree (which appears to also be in the rr tree) and commit
> > e5e62fcd081b0837f6210eb4ed022e9d8920bc59 ("stop_machine:simplify")
> > from the rr tree.
> >
> > I used the version in the rr tree.  Probably worth a look when I
> > publish the tree.
>
> hm, is there any difference between the content of the two commits?
>
> The "home tree" of the commit is tip/sched/new-API-sched_setscheduler,
> and that's integrated to the auto-sched-next branch. If there's any
> update to the patch we should iterate it there.

No they should be identical.  It's just that my stop_machine patch happens to 
use it.

Rusty.

Re: linux-next: manual merge of the rr tree

[Rusty Russell]

On Thursday 03 July 2008 18:19:06 Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > The "home tree" of the commit is
> > > tip/sched/new-API-sched_setscheduler, and that's integrated to the
> > > auto-sched-next branch. If there's any update to the patch we should
> > > iterate it there.
> >
> > That would be a question for Rusty.  He may be able to split out the
> > conflicting part of his simplification patch and send it to you.  But
> > it may not be worth it.
>
> should be all OK as long as Rusty sends his patches to Linus after the
> -tip changes go upstream. (in that case the base patch will fall out of
> Rusty's Quilt queue naturally, leaving the followup change.)

That's the plan.  I'm still testing the stop_machine changes though: it's 
simpler, but seems to have increased latency slightly.   If I was completely 
sure I'd just shuffle it to Ingo.

Cheers,
Rusty.

linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

Hi Rusty,

Today's linux-next merge of the rr tree got a trivial conflict in
kernel/sysctl.c between commit b0fc494fae96a7089f3651cb451f461c7291244c
("ftrace: add ftrace_enabled sysctl to disable mcount function") from the
ftrace tree and commit c1f560972a23262cfee0ffeacc3a435f61f0af09 ("remove
CONFIG_KMOD from core kernel code") from the rr tree.

Just a couple of contextual changes. Simple fixup.  I can carry it.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]

Hi Rusty,

Today's linux-next merge of the rr tree got conflicts in
drivers/net/tun.c and include/linux/if_tun.h between commits
07240fd0902c872f044f523893364a1a24c9f278 ("tun: Interface to query
tun/tap features"), 5228ddc98fa49b3cedab4024e269d62410a0d806 ("tun:
TUNSETFEATURES to set gso features") and
f271b2cc78f09c93ccd00a2056d3237134bf994c ("tun: Fix/rewrite packet
filtering logic") from the net tree and commit
10c9db38e381599da1491d7d5e71f13573d39144 ("misc:tun-gso-csum-features")
from the rr tree.

These are essentially the same changes in both trees (but with some
additions in the net tree.  I fixed it up as best I could.  It is
probably worth a look once the tree is published.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: manual merge of the rr tree

[Max Krasnyansky]

Stephen Rothwell wrote:
> Hi Rusty,
> 
> Today's linux-next merge of the rr tree got conflicts in
> drivers/net/tun.c and include/linux/if_tun.h between commits
> 07240fd0902c872f044f523893364a1a24c9f278 ("tun: Interface to query
> tun/tap features"), 5228ddc98fa49b3cedab4024e269d62410a0d806 ("tun:
> TUNSETFEATURES to set gso features") and
> f271b2cc78f09c93ccd00a2056d3237134bf994c ("tun: Fix/rewrite packet
> filtering logic") from the net tree and commit
> 10c9db38e381599da1491d7d5e71f13573d39144 ("misc:tun-gso-csum-features")
> from the rr tree.
> 
> These are essentially the same changes in both trees (but with some
> additions in the net tree.  I fixed it up as best I could.  It is
> probably worth a look once the tree is published.

I'm not sure what rr tree is. I'd suggest dropping tun patches from it and
just going with Dave's tree since everything should be already there.
ie I did my patches latest patches on top of Rusty's patches. And Dave already
merged all of them.

Max

Re: linux-next: manual merge of the rr tree

[Rusty Russell]

On Thursday 17 July 2008 15:46:05 Max Krasnyansky wrote:
> Stephen Rothwell wrote:
> > These are essentially the same changes in both trees (but with some
> > additions in the net tree.  I fixed it up as best I could.  It is
> > probably worth a look once the tree is published.
>
> I'm not sure what rr tree is. I'd suggest dropping tun patches from it and
> just going with Dave's tree since everything should be already there.
> ie I did my patches latest patches on top of Rusty's patches. And Dave
> already merged all of them.

Yep, -rr is my tree.  This duplicate is totally expected now Dave has merged, 
and will vanish once Linus gets them and I rebase.

Cheers,
Rusty.

linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
kernel/stop_machine.c between commit
65c011845316d3c1381f478ca0d8265c43b3b039 ("cpumask: Replace
cpumask_of_cpu with cpumask_of_cpu_ptr") from the cpus4096 tree and
commit 775664f6fd1530f5c90a7e55984459fd8cbb74a5 ("stop_machine:simplify")
(and some later commits) from the rr tree.

The update done in the former seems not to be needed any more, so I used
the version of this file from the rr tree.  Someone should check.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: manual merge of the rr tree

[Mike Travis]

Stephen Rothwell wrote:
> Hi Rusty,
> 
> Today's linux-next merge of the rr tree got a conflict in
> kernel/stop_machine.c between commit
> 65c011845316d3c1381f478ca0d8265c43b3b039 ("cpumask: Replace
> cpumask_of_cpu with cpumask_of_cpu_ptr") from the cpus4096 tree and
> commit 775664f6fd1530f5c90a7e55984459fd8cbb74a5 ("stop_machine:simplify")
> (and some later commits) from the rr tree.
> 
> The update done in the former seems not to be needed any more, so I used
> the version of this file from the rr tree.  Someone should check.
> 

Yes, it looks like you are correct.  The older code from cpus4096 is not
needed for kernel/stop_machine.c.  I'll look through the other changes and
send a note if there's any other issues.

Thanks!
Mike

linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

Hi Rusty,

Today's linux-next merge of the rr tree got a very trivial conflict in
drivers/char/hvc_irq.c between commit
611e097d7707741a336a0677d9d69bec40f29f3d ("hvc_console: rework setup to
replace irq functions with callbacks") from Linus' tree and commit
30b3dcfc04fd3948938e0c7c4a14ca8c50d16839
("misc:hvc_console_rework_setup_to_replace_irq_functions_with_callbacks")
from the rr tree (which is presumbaly the same patch, just whitespace
modified in Linus' tree.

Someone removed the extra blank line at the end of the file ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
fs/reiserfs/journal.c between commit
afe70259076fff0446001eaa1a287f615241a357 ("reiserfs: convert j_flush_sem
to mutex") from Linus' tree and commit
fd0eea245ccc61779d3155066d21a06fe3320524
("misc:down_nowait-fs_reiserfs_journal") from the rr tree.

The former commit changed the semaphore to a mutex, so I expect the
latter patch is no longer needed.  I used the version in Linus' tree.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
include/linux/kthread.h between commit
ed9559d38a87a44e3bda87d73a50aab92471d7dc ("Label kthread_create() with
printf attribute tag") from Linus' tree (which is also in the rr tree as
"misc:kthread-printf-attribute") and commit
b7298a2ec9cea26892cebb99916349e974b254fb ("misc:kthread-typesafe") from
the rr tree.

I used the rr tree version.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: manual merge of the rr tree

[Stephen Rothwell]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in kernel/module.c
between commits 9ac8b6586540c99a78ecc0162bde07eec3165f71 (driver core:
basic infrastructure for per-module dynamic debug messages"") (from the
driver-core tree), e543dff1468a55cdff9932dd3a806524790cf0b3 ("tracing:
Kernel Tracepoints"), be1c870c22e9b27170b5dd5028b6eaf2aab7b508 ("ftrace:
enable mcount recording for modules"),
61e679bf257baf9a089641999cf618e92f07b5dd ("ftrace: remove old pointers to
mcount") (from the ftrace tree) and commit
7e3f5b32db2fdb84b552a1f9d6e12da5fd48b2d9 ("module:simplify-load_module")
from the rr tree.

Overlapping additions/removals.  I fixed it up (see below) and can carry
the fixup.  It is probably worth a careful check of this fix.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc kernel/module.c
index 47c42ec,5292adb..0000000
--- a/kernel/module.c
+++ b/kernel/module.c
@@@ -42,13 -42,11 +42,14 @@@
  #include <linux/string.h>
  #include <linux/mutex.h>
  #include <linux/unwind.h>
+ #include <linux/rculist.h>
  #include <asm/uaccess.h>
  #include <asm/cacheflush.h>
 +#include <asm/sections.h>
  #include <linux/license.h>
  #include <asm/sections.h>
 +#include <linux/tracepoint.h>
 +#include <linux/ftrace.h>
  
  #if 0
  #define DEBUGP printk
@@@ -1843,37 -1822,13 +1856,16 @@@ static noinline struct module *load_mod
  	unsigned int i;
  	unsigned int symindex = 0;
  	unsigned int strindex = 0;
- 	unsigned int setupindex;
- 	unsigned int exindex;
- 	unsigned int exportindex;
- 	unsigned int modindex;
- 	unsigned int obsparmindex;
- 	unsigned int infoindex;
- 	unsigned int gplindex;
- 	unsigned int crcindex;
- 	unsigned int gplcrcindex;
- 	unsigned int versindex;
- 	unsigned int pcpuindex;
- 	unsigned int gplfutureindex;
- 	unsigned int gplfuturecrcindex;
+ 	unsigned int modindex, versindex, infoindex, pcpuindex;
  	unsigned int unwindex = 0;
- #ifdef CONFIG_UNUSED_SYMBOLS
- 	unsigned int unusedindex;
- 	unsigned int unusedcrcindex;
- 	unsigned int unusedgplindex;
- 	unsigned int unusedgplcrcindex;
- #endif
- 	unsigned int markersindex;
- 	unsigned int markersstringsindex;
 +	unsigned int verboseindex;
- 	unsigned int tracepointsindex;
- 	unsigned int tracepointsstringsindex;
- 	unsigned int mcountindex;
++	unsigned int mcountsize;
+ 	unsigned int num_kp;
+ 	struct kernel_param *kp;
  	struct module *mod;
  	long err = 0;
  	void *percpu = NULL, *ptr = NULL; /* Stops spurious gcc warning */
 +	void *mseg;
- 	struct exception_table_entry *extable;
  	mm_segment_t old_fs;
  
  	DEBUGP("load_module: umod=%p, len=%lu, uargs=%p\n",
@@@ -2109,42 -2049,51 +2086,56 @@@
  	if (err < 0)
  		goto cleanup;
  
- 	/* Set up EXPORTed & EXPORT_GPLed symbols (section 0 is 0 length) */
- 	mod->num_syms = sechdrs[exportindex].sh_size / sizeof(*mod->syms);
- 	mod->syms = (void *)sechdrs[exportindex].sh_addr;
- 	if (crcindex)
- 		mod->crcs = (void *)sechdrs[crcindex].sh_addr;
- 	mod->num_gpl_syms = sechdrs[gplindex].sh_size / sizeof(*mod->gpl_syms);
- 	mod->gpl_syms = (void *)sechdrs[gplindex].sh_addr;
- 	if (gplcrcindex)
- 		mod->gpl_crcs = (void *)sechdrs[gplcrcindex].sh_addr;
- 	mod->num_gpl_future_syms = sechdrs[gplfutureindex].sh_size /
- 					sizeof(*mod->gpl_future_syms);
- 	mod->gpl_future_syms = (void *)sechdrs[gplfutureindex].sh_addr;
- 	if (gplfuturecrcindex)
- 		mod->gpl_future_crcs = (void *)sechdrs[gplfuturecrcindex].sh_addr;
+ 	/* Now we've got everything in the final locations, we can
+ 	 * find optional sections. */
+ 	kp = section_objs(hdr, sechdrs, secstrings, "__param", sizeof(*kp),
+ 			  &num_kp);
+ 	mod->syms = section_objs(hdr, sechdrs, secstrings, "__ksymtab",
+ 				 sizeof(*mod->syms), &mod->num_syms);
+ 	mod->crcs = section_addr(hdr, sechdrs, secstrings, "__kcrctab");
+ 	mod->gpl_syms = section_objs(hdr, sechdrs, secstrings, "__ksymtab_gpl",
+ 				     sizeof(*mod->gpl_syms),
+ 				     &mod->num_gpl_syms);
+ 	mod->gpl_crcs = section_addr(hdr, sechdrs, secstrings, "__kcrctab_gpl");
+ 	mod->gpl_future_syms = section_objs(hdr, sechdrs, secstrings,
+ 					    "__ksymtab_gpl_future",
+ 					    sizeof(*mod->gpl_future_syms),
+ 					    &mod->num_gpl_future_syms);
+ 	mod->gpl_future_crcs = section_addr(hdr, sechdrs, secstrings,
+ 					    "__kcrctab_gpl_future");
  
  #ifdef CONFIG_UNUSED_SYMBOLS
- 	mod->num_unused_syms = sechdrs[unusedindex].sh_size /
- 					sizeof(*mod->unused_syms);
- 	mod->num_unused_gpl_syms = sechdrs[unusedgplindex].sh_size /
- 					sizeof(*mod->unused_gpl_syms);
- 	mod->unused_syms = (void *)sechdrs[unusedindex].sh_addr;
- 	if (unusedcrcindex)
- 		mod->unused_crcs = (void *)sechdrs[unusedcrcindex].sh_addr;
- 	mod->unused_gpl_syms = (void *)sechdrs[unusedgplindex].sh_addr;
- 	if (unusedgplcrcindex)
- 		mod->unused_gpl_crcs
- 			= (void *)sechdrs[unusedgplcrcindex].sh_addr;
+ 	mod->unused_syms = section_objs(hdr, sechdrs, secstrings,
+ 					"__ksymtab_unused",
+ 					sizeof(*mod->unused_syms),
+ 					&mod->num_unused_syms);
+ 	mod->unused_crcs = section_addr(hdr, sechdrs, secstrings,
+ 					"__kcrctab_unused");
+ 	mod->unused_gpl_syms = section_objs(hdr, sechdrs, secstrings,
+ 					    "__ksymtab_unused_gpl",
+ 					    sizeof(*mod->unused_gpl_syms),
+ 					    &mod->num_unused_gpl_syms);
+ 	mod->unused_gpl_crcs = section_addr(hdr, sechdrs, secstrings,
+ 					    "__kcrctab_unused_gpl");
+ #endif
+ 
+ #ifdef CONFIG_MARKERS
+ 	mod->markers = section_objs(hdr, sechdrs, secstrings, "__markers",
+ 				    sizeof(*mod->markers), &mod->num_markers);
+ #endif
++#ifdef CONFIG_TRACEPOINTS
++	mod->tracepoints = section_objs(hdr, sechdrs, secstrings,
++				"__tracepoints", sizeof(*mod->tracepoints),
++				&mod->num_tracepoints);
 +#endif
  
  #ifdef CONFIG_MODVERSIONS
- 	if ((mod->num_syms && !crcindex)
- 	    || (mod->num_gpl_syms && !gplcrcindex)
- 	    || (mod->num_gpl_future_syms && !gplfuturecrcindex)
+ 	if ((mod->num_syms && !mod->crcs)
+ 	    || (mod->num_gpl_syms && !mod->gpl_crcs)
+ 	    || (mod->num_gpl_future_syms && !mod->gpl_future_crcs)
  #ifdef CONFIG_UNUSED_SYMBOLS
- 	    || (mod->num_unused_syms && !unusedcrcindex)
- 	    || (mod->num_unused_gpl_syms && !unusedgplcrcindex)
+ 	    || (mod->num_unused_syms && !mod->unused_crcs)
+ 	    || (mod->num_unused_gpl_syms && !mod->unused_gpl_crcs)
  #endif
  		) {
  		printk(KERN_WARNING "%s: No versions for exported symbols.\n", mod->name);
@@@ -2153,16 -2102,6 +2144,7 @@@
  			goto cleanup;
  	}
  #endif
- 	markersindex = find_sec(hdr, sechdrs, secstrings, "__markers");
-  	markersstringsindex = find_sec(hdr, sechdrs, secstrings,
- 					"__markers_strings");
 +	verboseindex = find_sec(hdr, sechdrs, secstrings, "__verbose");
- 	tracepointsindex = find_sec(hdr, sechdrs, secstrings, "__tracepoints");
- 	tracepointsstringsindex = find_sec(hdr, sechdrs, secstrings,
- 					"__tracepoints_strings");
- 
- 	mcountindex = find_sec(hdr, sechdrs, secstrings,
- 			       "__mcount_loc");
  
  	/* Now do relocations. */
  	for (i = 1; i < hdr->e_shnum; i++) {
@@@ -2219,17 -2145,7 +2189,18 @@@
  		marker_update_probe_range(mod->markers,
  			mod->markers + mod->num_markers);
  #endif
 +#ifdef CONFIG_TRACEPOINTS
 +		tracepoint_update_probe_range(mod->tracepoints,
 +			mod->tracepoints + mod->num_tracepoints);
 +#endif
 +	}
 +	dynamic_printk_setup(sechdrs, verboseindex);
 +
 +	/* sechdrs[0].sh_size is always zero */
- 	mseg = (void *)sechdrs[mcountindex].sh_addr;
- 	ftrace_init_module(mseg, mseg + sechdrs[mcountindex].sh_size);
++	mseg = section_objs(hdr, sechdrs, secstrings,
++			       "__mcount_loc", 1, &mcountsize);
++	ftrace_init_module(mseg, mseg + mcountsize);
 +
  	err = module_finalize(hdr, sechdrs, mod);
  	if (err < 0)
  		goto cleanup;

linux-next: manual merge of the rr tree

[Stephen Rothwell]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
arch/x86/Kconfig between commit 363a5e3d7b4b69371f21bcafd7fc76e68c73733a
("x86: add MAXSMP") from cpus4096 tree and commit
7ff10dbd907d18bb26b1a8e8ac4ec32a72c0d0ee ("x86:enable-MAXSMP") from the
rr tree.

Overlapping changes. I have fixed it up (see below) and can carry the fix.

There is also a conflict in the same file between commit
01f569c81fc075f276ec2e7c0b7cb4c72ba74635 ("x86: restore 4096 limit for
NR_CPUS") from the cpus4096 tree and commit
d08dde18aebb15633e5c4480814b77d93a4d68f6
("cpumask:CONFIG_NR_CPUS-always") from the rr tree.

Overlapping changes.  I have fixed it up (see below) and can carry the fix.

Rusty, your versions of these patches also had some leading spaces ...
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc arch/x86/Kconfig
index fa5e00e,cf8b5d9..0000000
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@@ -575,24 -572,20 +575,25 @@@ config IOMMU_HELPE
  
  config MAXSMP
  	bool "Configure Maximum number of SMP Processors and NUMA Nodes"
 - 	depends on X86_64 && SMP && DEBUG_KERNEL && EXPERIMENTAL
 +	depends on X86_64 && SMP && DEBUG_KERNEL && EXPERIMENTAL
+ 	select CPUMASK_OFFSTACK
 -	default n
  	help
 -	  Configure maximum number of CPUS and NUMA Nodes for this architecture.
 +	  Configure maximum number of CPUS and NUMA Nodes for this
 +	  architecture (up to 4096!).
 +
 +	  This can increase memory usage, bigger stack footprint and can
 +	  add some runtime overhead as well so unless you want a generic
 +	  distro kernel you likely want to say N.
 +
  	  If unsure, say N.
  
  config NR_CPUS
- 	int "Maximum number of CPUs (2-4096)" if !MAXSMP
- 	range 2 4096
- 	depends on SMP
 - 	int "Maximum number of CPUs" if SMP && !MAXSMP
 - 	range 2 512 if SMP && !MAXSMP
++	int "Maximum number of CPUs (2-4096)" if SMP && !MAXSMP
++	range 2 4096 if SMP && !MAXSMP
+ 	default "1" if !SMP
 - 	default "4096" if MAXSMP
 +	default "4096" if MAXSMP
- 	default "32" if X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || X86_ES7000
- 	default "8"
+ 	default "32" if SMP && (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || X86_ES7000)
+ 	default "8" if SMP
  	help
  	  This allows you to specify the maximum number of CPUs which this
  	  kernel will support.  The maximum supported value is 512 and the

linux-next: manual merge of the rr tree

[Stephen Rothwell]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in kernel/sched.c
between commit tg_shares_up ("sched: optimize group load balancer") from
the sched tree and commit 1a39c64ec96acde2a0f43bbe408efc328541a73e
("cpumask:for_each_cpu") from the rr tree.

Overlapping changes.  I fixed it up (see below) and can carry the fix.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc kernel/sched.c
index 2d76674,c7da251..0000000
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@@ -1538,8 -1527,14 +1538,8 @@@ static int tg_shares_up(struct task_gro
  	if (!rq_weight)
  		rq_weight = cpus_weight(sd->span) * NICE_0_LOAD;
  
- 	for_each_cpu_mask(i, sd->span)
 -	for_each_cpu(i, &sd->span) {
 -		struct rq *rq = cpu_rq(i);
 -		unsigned long flags;
 -
 -		spin_lock_irqsave(&rq->lock, flags);
 -		__update_group_shares_cpu(tg, i, shares, rq_weight);
 -		spin_unlock_irqrestore(&rq->lock, flags);
 -	}
++	for_each_cpu(i, &sd->span)
 +		update_group_shares_cpu(tg, i, shares, rq_weight);
  
  	return 0;
  }

linux-next: manual merge of the rr tree

[Stephen Rothwell]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in kernel/smp.c
between commit 562d8c23497402eb7eb9caf8dab84439a03a49ea ("smp: reduce
stack requirements for smp_call_function_mask") from the cpus4096 tree
and commit  ("1855648ee0b5ed8fe800edf401bbe25a3f2ed94a") from the rr tree.

Overlapping changes.  I have used the version from the rr tree, but I am
not sure if that is the correct thing to do.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Re: linux-next: manual merge of the rr tree

[Rusty Russell]

On Thursday 23 October 2008 15:12:41 Stephen Rothwell wrote:
> Hi Rusty,
>
> Today's linux-next merge of the rr tree got a conflict in kernel/smp.c
> between commit 562d8c23497402eb7eb9caf8dab84439a03a49ea ("smp: reduce
> stack requirements for smp_call_function_mask") from the cpus4096 tree
> and commit  ("1855648ee0b5ed8fe800edf401bbe25a3f2ed94a") from the rr tree.
>
> Overlapping changes.  I have used the version from the rr tree, but I am
> not sure if that is the correct thing to do.

Mike?

Rusty.

Re: linux-next: manual merge of the rr tree

[Peter Zijlstra]

On Thu, 2008-10-23 at 15:01 +1100, Stephen Rothwell wrote:
> 
> Hi Rusty,
> 
> Today's linux-next merge of the rr tree got a conflict in
> kernel/sched.c
> between commit tg_shares_up ("sched: optimize group load balancer")
> from
> the sched tree and commit 1a39c64ec96acde2a0f43bbe408efc328541a73e
> ("cpumask:for_each_cpu") from the rr tree.
> 
> Overlapping changes.  I fixed it up (see below) and can carry the fix.

Looks good, thanks!

> diff --cc kernel/sched.c
> index 2d76674,c7da251..0000000
> --- a/kernel/sched.c
> +++ b/kernel/sched.c
> @@@ -1538,8 -1527,14 +1538,8 @@@ static int tg_shares_up(struct
> task_gro
>         if (!rq_weight)
>                 rq_weight = cpus_weight(sd->span) * NICE_0_LOAD;
>   
> -       for_each_cpu_mask(i, sd->span)
>  -      for_each_cpu(i, &sd->span) {
>  -              struct rq *rq = cpu_rq(i);
>  -              unsigned long flags;
>  -
>  -              spin_lock_irqsave(&rq->lock, flags);
>  -              __update_group_shares_cpu(tg, i, shares, rq_weight);
>  -              spin_unlock_irqrestore(&rq->lock, flags);
>  -      }
> ++      for_each_cpu(i, &sd->span)
>  +              update_group_shares_cpu(tg, i, shares, rq_weight);
>   
>         return 0;
>   }

Re: linux-next: manual merge of the rr tree

[Rusty Russell]

On Thursday 23 October 2008 14:56:02 Stephen Rothwell wrote:
> Hi Rusty,
>
> Today's linux-next merge of the rr tree got a conflict in
> arch/x86/Kconfig between commit 363a5e3d7b4b69371f21bcafd7fc76e68c73733a
> ("x86: add MAXSMP") from cpus4096 tree and commit
> 7ff10dbd907d18bb26b1a8e8ac4ec32a72c0d0ee ("x86:enable-MAXSMP") from the
> rr tree.

OK, this is a real conflict, your fix looks good.

> There is also a conflict in the same file between commit
> 01f569c81fc075f276ec2e7c0b7cb4c72ba74635 ("x86: restore 4096 limit for
> NR_CPUS") from the cpus4096 tree and commit
> d08dde18aebb15633e5c4480814b77d93a4d68f6
> ("cpumask:CONFIG_NR_CPUS-always") from the rr tree.
>
> Overlapping changes.  I have fixed it up (see below) and can carry the fix.
>
> Rusty, your versions of these patches also had some leading spaces ...

Hmm, it did too.  checkpatch.pl doesn't comment on it.  Fixed.

Thanks,
Rusty.

Re: linux-next: manual merge of the rr tree

[Rusty Russell]

On Thursday 23 October 2008 16:16:11 Rusty Russell wrote:
> On Thursday 23 October 2008 15:12:41 Stephen Rothwell wrote:
> > Hi Rusty,
> >
> > Today's linux-next merge of the rr tree got a conflict in kernel/smp.c
> > between commit 562d8c23497402eb7eb9caf8dab84439a03a49ea ("smp: reduce
> > stack requirements for smp_call_function_mask") from the cpus4096 tree
> > and commit  ("1855648ee0b5ed8fe800edf401bbe25a3f2ed94a") from the rr
> > tree.
> >
> > Overlapping changes.  I have used the version from the rr tree, but I am
> > not sure if that is the correct thing to do.
>
> Mike?

OK, Ingo has the older September version.  Your call was correct.

Rusty.

Re: linux-next: manual merge of the rr tree

[Mike Travis]

Rusty Russell wrote:
> On Thursday 23 October 2008 15:12:41 Stephen Rothwell wrote:
>> Hi Rusty,
>>
>> Today's linux-next merge of the rr tree got a conflict in kernel/smp.c
>> between commit 562d8c23497402eb7eb9caf8dab84439a03a49ea ("smp: reduce
>> stack requirements for smp_call_function_mask") from the cpus4096 tree
>> and commit  ("1855648ee0b5ed8fe800edf401bbe25a3f2ed94a") from the rr tree.
>>
>> Overlapping changes.  I have used the version from the rr tree, but I am
>> not sure if that is the correct thing to do.
> 
> Mike?
> 
> Rusty.

Hi,

Yes, I just started looking at them... Did you push upstream the last
version I sent last night?  Or perhaps my view of the tip tree doesn't
include the cpus4096 tree?

I'll update my linux-next tree and examine the conflicts.

Thanks!

(And Thanks Stephen for dealing with these!  Sorry for the headaches.)

Mike

Re: linux-next: manual merge of the rr tree

[Rusty Russell]

On Thursday 23 October 2008 15:01:30 Stephen Rothwell wrote:
> Hi Rusty,
>
> Today's linux-next merge of the rr tree got a conflict in kernel/sched.c
> between commit tg_shares_up ("sched: optimize group load balancer") from
> the sched tree and commit 1a39c64ec96acde2a0f43bbe408efc328541a73e
> ("cpumask:for_each_cpu") from the rr tree.
>
> Overlapping changes.  I fixed it up (see below) and can carry the fix.

Ideal.

Thanks,
Rusty.

linux-next: manual merge of the rr tree

[Stephen Rothwell]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
arch/x86/include/asm/ipi.h between commit
1965aae3c98397aad957412413c07e97b1bd4e64 ("x86: Fix ASM_X86__ header
guards") from Linus' tree and commit
8bb673a4d8312a71783b8ff190622fd03dfe34b8 ("x86 smp: modify send_IPI_mask
interface to accept cpumask_t pointers") from the rr tree.

Just trivial context changes.  I fixed it up (see below).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc arch/x86/include/asm/ipi.h
index f89dffb,fcb7424..0000000
--- a/arch/x86/include/asm/ipi.h
+++ b/arch/x86/include/asm/ipi.h
@@@ -135,4 -135,21 +135,21 @@@ static inline void send_IPI_mask_sequen
  	local_irq_restore(flags);
  }
  
+ static inline void send_IPI_mask_allbutself(const cpumask_t *mask, int vector)
+ {
+ 	unsigned long flags;
+ 	unsigned int query_cpu;
+ 	unsigned int this_cpu = smp_processor_id();
+ 
+ 	/* See Hack comment above */
+ 
+ 	local_irq_save(flags);
+ 	for_each_cpu_mask_nr(query_cpu, *mask)
+ 		if (query_cpu != this_cpu)
+ 			__send_IPI_dest_field(
+ 				per_cpu(x86_cpu_to_apicid, query_cpu),
+ 				vector, APIC_DEST_PHYSICAL);
+ 	local_irq_restore(flags);
+ }
+ 
 -#endif /* ASM_X86__IPI_H */
 +#endif /* _ASM_X86_IPI_H */

linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
kernel/stop_machine.c between commit
4403b406d4369a275d483ece6ddee0088cc0d592 ("Revert "Call init_workqueues
before pre smp initcalls."") from Linus' tree and commit
b9d4c68d4c404c48c20380ff25fd8c0202921a96 ("commit a802dd0e breaks console
keyboard input") from the rr tree.

Two different fixes.  I used the one in the rr tree for now.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: manual merge of the rr tree

[Stephen Rothwell]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
arch/s390/Kconfig between commit 0d2a4a69f5a01c8886323afe742487f35493e209
("[S390] convert s390 to generic IPI infrastructure") from the s390 tree
and commit a5f0c6822e6795927091d756c51b51320305654a
("cpumask:centralize-common-maps") from the rr tree.

Just overlapping additions.  I fixed it up (see below) and can carry the fix.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc arch/s390/Kconfig
index abcc7f9,f7270d5..0000000
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@@ -78,7 -75,7 +78,8 @@@ config S39
  	select HAVE_KRETPROBES
  	select HAVE_KVM if 64BIT
  	select HAVE_ARCH_TRACEHOOK
 +	select USE_GENERIC_SMP_HELPERS if SMP
+ 	select INIT_ALL_POSSIBLE
  
  source "init/Kconfig"
  

Re: linux-next: manual merge of the rr tree

[Heiko Carstens]

On Tue, Oct 28, 2008 at 01:55:58PM +1100, Stephen Rothwell wrote:
> Hi Rusty,
> 
> Today's linux-next merge of the rr tree got a conflict in
> arch/s390/Kconfig between commit 0d2a4a69f5a01c8886323afe742487f35493e209
> ("[S390] convert s390 to generic IPI infrastructure") from the s390 tree
> and commit a5f0c6822e6795927091d756c51b51320305654a
> ("cpumask:centralize-common-maps") from the rr tree.
> 
> Just overlapping additions.  I fixed it up (see below) and can carry the fix.
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
> 
> diff --cc arch/s390/Kconfig
> index abcc7f9,f7270d5..0000000
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@@ -78,7 -75,7 +78,8 @@@ config S39
>   	select HAVE_KRETPROBES
>   	select HAVE_KVM if 64BIT
>   	select HAVE_ARCH_TRACEHOOK
>  +	select USE_GENERIC_SMP_HELPERS if SMP
> + 	select INIT_ALL_POSSIBLE

I will move the USE_GENERIC_SMP_HELPERS select to the top, so the merge
conflict should be resolved in future.

Re: linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 341 bytes --]

Hi Heiko,

On Tue, 28 Oct 2008 08:19:31 +0100 Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
>
> I will move the USE_GENERIC_SMP_HELPERS select to the top, so the merge
> conflict should be resolved in future.

OK, thanks.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

Hi Rusty,

Today's linux-next merge of the rr tree got quite a few conflicts - too
many for me to fix up right now.  I shall drop it for today and try again
tomorrow.

One thing:  You need to sort out where patches belong as at least one
change that conflicted was because different versions of the same fix was
applied to the rr and cpus4096 trees.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

P.S. looking at commit dba205acec6f7db0b53abdf5b26802c19c0d9abf
("cpumask: fixlets") from the cpus4096 tree, "Signed-of-by: has two
'f's :-)

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3939 bytes --]

Hi Rusty,

On Wed, 29 Oct 2008 15:28:49 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the rr tree got quite a few conflicts - too
> many for me to fix up right now.  I shall drop it for today and try again
> tomorrow.

The attempted merge went like this:

$ git merge quilt/rr
Renamed include/asm-x86/bigsmp/apic.h => arch/x86/include/asm/bigsmp/apic.h
Auto-merged arch/x86/include/asm/bigsmp/apic.h
CONFLICT (rename/modify): Merge conflict in arch/x86/include/asm/bigsmp/apic.h
Renamed include/asm-x86/es7000/apic.h => arch/x86/include/asm/es7000/apic.h
Auto-merged arch/x86/include/asm/es7000/apic.h
CONFLICT (rename/modify): Merge conflict in arch/x86/include/asm/es7000/apic.h
Renamed include/asm-x86/genapic_64.h => arch/x86/include/asm/genapic_64.h
Auto-merged arch/x86/include/asm/genapic_64.h
Renamed include/asm-x86/ipi.h => arch/x86/include/asm/ipi.h
Auto-merged arch/x86/include/asm/ipi.h
CONFLICT (rename/modify): Merge conflict in arch/x86/include/asm/ipi.h
Renamed include/asm-x86/mach-default/mach_apic.h => arch/x86/include/asm/mach-default/mach_apic.h
Auto-merged arch/x86/include/asm/mach-default/mach_apic.h
CONFLICT (rename/modify): Merge conflict in arch/x86/include/asm/mach-default/mach_apic.h
Auto-merged Documentation/lguest/lguest.c
Auto-merged arch/alpha/kernel/smp.c
Auto-merged arch/ia64/kernel/acpi.c
Auto-merged arch/ia64/kernel/perfmon.c
Auto-merged arch/ia64/kernel/setup.c
Auto-merged arch/mips/kernel/smp.c
Auto-merged arch/powerpc/kernel/machine_kexec_64.c
Auto-merged arch/powerpc/kernel/setup-common.c
Auto-merged arch/powerpc/mm/numa.c
Auto-merged arch/powerpc/platforms/cell/spu_base.c
CONFLICT (content): Merge conflict in arch/powerpc/platforms/cell/spu_base.c
Auto-merged arch/s390/Kconfig
Auto-merged arch/s390/kernel/smp.c
Auto-merged arch/sh/kernel/smp.c
Auto-merged arch/x86/Kconfig
CONFLICT (content): Merge conflict in arch/x86/Kconfig
Auto-merged arch/x86/kernel/genapic_flat_64.c
Auto-merged arch/x86/kernel/genx2apic_cluster.c
CONFLICT (content): Merge conflict in arch/x86/kernel/genx2apic_cluster.c
Auto-merged arch/x86/kernel/genx2apic_phys.c
CONFLICT (content): Merge conflict in arch/x86/kernel/genx2apic_phys.c
Auto-merged arch/x86/kernel/genx2apic_uv_x.c
CONFLICT (content): Merge conflict in arch/x86/kernel/genx2apic_uv_x.c
Auto-merged arch/x86/kernel/setup_percpu.c
Auto-merged arch/x86/kernel/smpboot.c
Auto-merged drivers/net/virtio_net.c
Auto-merged drivers/pci/pci-sysfs.c
Auto-merged drivers/pci/probe.c
Auto-merged include/linux/cpumask.h
CONFLICT (content): Merge conflict in include/linux/cpumask.h
Auto-merged include/linux/workqueue.h
Auto-merged init/Kconfig
Auto-merged init/main.c
Auto-merged kernel/Kconfig.preempt
CONFLICT (content): Merge conflict in kernel/Kconfig.preempt
Auto-merged kernel/cpu.c
CONFLICT (content): Merge conflict in kernel/cpu.c
Auto-merged kernel/irq/proc.c
Auto-merged kernel/module.c
Auto-merged kernel/panic.c
Auto-merged kernel/params.c
CONFLICT (content): Merge conflict in kernel/params.c
Auto-merged kernel/sched.c
CONFLICT (content): Merge conflict in kernel/sched.c
Auto-merged kernel/sched_stats.h
Auto-merged kernel/smp.c
Auto-merged kernel/stop_machine.c
CONFLICT (content): Merge conflict in kernel/stop_machine.c
Auto-merged kernel/time/timer_list.c
Auto-merged kernel/trace/trace.c
Auto-merged kernel/workqueue.c
Auto-merged lib/Kconfig.debug
CONFLICT (content): Merge conflict in lib/Kconfig.debug
Auto-merged lib/cpumask.c
CONFLICT (content): Merge conflict in lib/cpumask.c
Auto-merged mm/slub.c
Auto-merged mm/vmstat.c
Auto-merged net/core/neighbour.c
Auto-merged net/ipv4/route.c

At least the move of the include files from include/asm-x86 to
arch/x86/include is now in Linus' tree.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: manual merge of the rr tree

[Rusty Russell]

On Wednesday 29 October 2008 15:28:49 Stephen Rothwell wrote:
> Hi Rusty,
>
> Today's linux-next merge of the rr tree got quite a few conflicts - too
> many for me to fix up right now.  I shall drop it for today and try again
> tomorrow.
>
> One thing:  You need to sort out where patches belong as at least one
> change that conflicted was because different versions of the same fix was
> applied to the rr and cpus4096 trees.

We were hoping Linus would take the cpumask API patches this time around so 
this issue would vanish.  I've moved them out of my -next tree for the 
moment.

After that, it's a matter of pushing conversion patches through misc. 
maintainers over the next cycle.

Thanks,
Rusty.

[PATCH] cpumask: introduce new API, without changing anything

[Rusty Russell]

(Tested in linux-next as well as locally.  Linus, please apply).

We want to deprecate cpumasks on the stack, as we are headed for
gynormous numbers of CPUs.  Eventually, we want to head towards an
undefined 'struct cpumask' so they can never be declared on stack.

1) New cpumask functions which take pointers instead of copies.
   (cpus_* -> cpumask_*)

2) Several new helpers to reduce requirements for temporary cpumasks
   (cpumask_first_and, cpumask_next_and, cpumask_any_and)

3) Helpers for declaring cpumasks on or offstack for large NR_CPUS
   (cpumask_var_t, alloc_cpumask_var and free_cpumask_var)

4) 'struct cpumask' for explicitness and to mark new-style code.

5) Make iterator functions stop at nr_cpu_ids (a runtime constant),
   not NR_CPUS for time efficiency and for smaller dynamic allocations
   in future.

6) cpumask_copy() so we can allocate less than a full cpumask eventually
   (for alloc_cpumask_var), and so we can eliminate the 'struct cpumask'
   definition eventually.

7) work_on_cpu() helper for doing task on a CPU, rather than saving old
   cpumask for current thread and manipulating it.

8) smp_call_function_many() which is smp_call_function_mask() except
   taking a cpumask pointer.

Note that this patch simply introduces the new functions and leaves
the obsolescent ones in place.  This is to simplify the transition
patches.

(Full kudos to co-author Mike for all the trial-and-error and haggling
over this new API).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Acked-by: Mike Travis <travis@sgi.com>
---
 include/linux/cpumask.h   |  513 +++++++++++++++++++++++++++++++++++++++++++++-
 include/linux/smp.h       |    9 
 include/linux/workqueue.h |    8 
 kernel/cpu.c              |    3 
 kernel/workqueue.c        |   45 ++++
 lib/cpumask.c             |   78 ++++++
 6 files changed, 654 insertions(+), 2 deletions(-)

diff -r 8f6fe5d6f181 include/linux/cpumask.h
--- a/include/linux/cpumask.h	Wed Nov 05 23:12:20 2008 +1100
+++ b/include/linux/cpumask.h	Fri Nov 07 00:15:12 2008 +1100
@@ -4,6 +4,9 @@
 /*
  * Cpumasks provide a bitmap suitable for representing the
  * set of CPU's in a system, one bit position per CPU number.
+ *
+ * The new cpumask_ ops take a "struct cpumask *"; the old ones
+ * use cpumask_t.
  *
  * See detailed comments in the file linux/bitmap.h describing the
  * data type on which these cpumasks are based.
@@ -31,7 +34,7 @@
  *       will span the entire range of NR_CPUS.
  * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  *
- * The available cpumask operations are:
+ * The obsolescent cpumask operations are:
  *
  * void cpu_set(cpu, mask)		turn on bit 'cpu' in mask
  * void cpu_clear(cpu, mask)		turn off bit 'cpu' in mask
@@ -138,7 +141,7 @@
 #include <linux/threads.h>
 #include <linux/bitmap.h>
 
-typedef struct { DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t;
+typedef struct cpumask { DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t;
 extern cpumask_t _unused_cpumask_arg_;
 
 #define cpu_set(cpu, dst) __cpu_set((cpu), &(dst))
@@ -527,4 +530,510 @@ extern cpumask_t cpu_active_map;
 #define for_each_online_cpu(cpu)   for_each_cpu_mask_nr((cpu), cpu_online_map)
 #define for_each_present_cpu(cpu)  for_each_cpu_mask_nr((cpu), cpu_present_map)
 
+/* These are the new versions of the cpumask operators: passed by pointer.
+ * The older versions will be implemented in terms of these, then deleted. */
+#define cpumask_bits(maskp) ((maskp)->bits)
+
+#if NR_CPUS <= BITS_PER_LONG
+#define CPU_BITS_ALL						\
+{								\
+	[BITS_TO_LONGS(NR_CPUS)-1] = CPU_MASK_LAST_WORD	\
+}
+
+/* This produces more efficient code. */
+#define nr_cpumask_bits	NR_CPUS
+
+#else /* NR_CPUS > BITS_PER_LONG */
+
+#define CPU_BITS_ALL						\
+{								\
+	[0 ... BITS_TO_LONGS(NR_CPUS)-2] = ~0UL,		\
+	[BITS_TO_LONGS(NR_CPUS)-1] = CPU_MASK_LAST_WORD		\
+}
+
+#define nr_cpumask_bits	nr_cpu_ids
+#endif /* NR_CPUS > BITS_PER_LONG */
+
+/* verify cpu argument to cpumask_* operators */
+static inline unsigned int cpumask_check(unsigned int cpu)
+{
+#ifdef CONFIG_DEBUG_PER_CPU_MAPS
+	WARN_ON_ONCE(cpu >= nr_cpumask_bits);
+#endif /* CONFIG_DEBUG_PER_CPU_MAPS */
+	return cpu;
+}
+
+#if NR_CPUS == 1
+/* Uniprocesor. */
+#define cpumask_first(src)		({ (void)(src); 0; })
+#define cpumask_next(n, src)		({ (void)(src); 1; })
+#define cpumask_next_zero(n, src)	({ (void)(src); 1; })
+#define cpumask_next_and(n, srcp, andp)	({ (void)(srcp), (void)(andp); 1; })
+#define cpumask_any_but(mask, cpu)	({ (void)(mask); (void)(cpu); 0; })
+
+#define for_each_cpu(cpu, mask)			\
+	for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)
+#define for_each_cpu_and(cpu, mask, and)	\
+	for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask, (void)and)
+#else
+/**
+ * cpumask_first - get the first cpu in a cpumask
+ * @srcp: the cpumask pointer
+ *
+ * Returns >= nr_cpu_ids if no cpus set.
+ */
+static inline unsigned int cpumask_first(const struct cpumask *srcp)
+{
+	return find_first_bit(cpumask_bits(srcp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_next - get the next cpu in a cpumask
+ * @n: the cpu prior to the place to search (ie. return will be > @n)
+ * @srcp: the cpumask pointer
+ *
+ * Returns >= nr_cpu_ids if no further cpus set.
+ */
+static inline unsigned int cpumask_next(int n, const struct cpumask *srcp)
+{
+	/* -1 is a legal arg here. */
+	if (n != -1)
+		cpumask_check(n);
+	return find_next_bit(cpumask_bits(srcp), nr_cpumask_bits, n+1);
+}
+
+/**
+ * cpumask_next_zero - get the next unset cpu in a cpumask
+ * @n: the cpu prior to the place to search (ie. return will be > @n)
+ * @srcp: the cpumask pointer
+ *
+ * Returns >= nr_cpu_ids if no further cpus unset.
+ */
+static inline unsigned int cpumask_next_zero(int n, const struct cpumask *srcp)
+{
+	/* -1 is a legal arg here. */
+	if (n != -1)
+		cpumask_check(n);
+	return find_next_zero_bit(cpumask_bits(srcp), nr_cpumask_bits, n+1);
+}
+
+int cpumask_next_and(int n, const struct cpumask *, const struct cpumask *);
+int cpumask_any_but(const struct cpumask *mask, unsigned int cpu);
+
+#define for_each_cpu(cpu, mask)				\
+	for ((cpu) = -1;				\
+		(cpu) = cpumask_next((cpu), (mask)),	\
+		(cpu) < nr_cpu_ids;)
+#define for_each_cpu_and(cpu, mask, and)				\
+	for ((cpu) = -1;						\
+		(cpu) = cpumask_next_and((cpu), (mask), (and)),		\
+		(cpu) < nr_cpu_ids;)
+#endif /* SMP */
+
+#define CPU_BITS_NONE						\
+{								\
+	[0 ... BITS_TO_LONGS(NR_CPUS)-1] = 0UL			\
+}
+
+#define CPU_BITS_CPU0						\
+{								\
+	[0] =  1UL						\
+}
+
+/**
+ * cpumask_set_cpu - set a cpu in a cpumask
+ * @cpu: cpu number (< nr_cpu_ids)
+ * @dstp: the cpumask pointer
+ */
+static inline void cpumask_set_cpu(unsigned int cpu, struct cpumask *dstp)
+{
+	set_bit(cpumask_check(cpu), cpumask_bits(dstp));
+}
+
+/**
+ * cpumask_clear_cpu - clear a cpu in a cpumask
+ * @cpu: cpu number (< nr_cpu_ids)
+ * @dstp: the cpumask pointer
+ */
+static inline void cpumask_clear_cpu(int cpu, struct cpumask *dstp)
+{
+	clear_bit(cpumask_check(cpu), cpumask_bits(dstp));
+}
+
+/**
+ * cpumask_test_cpu - test for a cpu in a cpumask
+ * @cpu: cpu number (< nr_cpu_ids)
+ * @cpumask: the cpumask pointer
+ *
+ * No static inline type checking - see Subtlety (1) above.
+ */
+#define cpumask_test_cpu(cpu, cpumask) \
+	test_bit(cpumask_check(cpu), (cpumask)->bits)
+
+/**
+ * cpumask_test_and_set_cpu - atomically test and set a cpu in a cpumask
+ * @cpu: cpu number (< nr_cpu_ids)
+ * @cpumask: the cpumask pointer
+ *
+ * test_and_set_bit wrapper for cpumasks.
+ */
+static inline int cpumask_test_and_set_cpu(int cpu, struct cpumask *cpumask)
+{
+	return test_and_set_bit(cpumask_check(cpu), cpumask_bits(cpumask));
+}
+
+/**
+ * cpumask_setall - set all cpus (< nr_cpu_ids) in a cpumask
+ * @dstp: the cpumask pointer
+ */
+static inline void cpumask_setall(struct cpumask *dstp)
+{
+	bitmap_fill(cpumask_bits(dstp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_clear - clear all cpus (< nr_cpu_ids) in a cpumask
+ * @dstp: the cpumask pointer
+ */
+static inline void cpumask_clear(struct cpumask *dstp)
+{
+	bitmap_zero(cpumask_bits(dstp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_and - *dstp = *src1p & *src2p
+ * @dstp: the cpumask result
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline void cpumask_and(struct cpumask *dstp,
+			       const struct cpumask *src1p,
+			       const struct cpumask *src2p)
+{
+	bitmap_and(cpumask_bits(dstp), cpumask_bits(src1p),
+				       cpumask_bits(src2p), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_or - *dstp = *src1p | *src2p
+ * @dstp: the cpumask result
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline void cpumask_or(struct cpumask *dstp, const struct cpumask *src1p,
+			      const struct cpumask *src2p)
+{
+	bitmap_or(cpumask_bits(dstp), cpumask_bits(src1p),
+				      cpumask_bits(src2p), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_xor - *dstp = *src1p ^ *src2p
+ * @dstp: the cpumask result
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline void cpumask_xor(struct cpumask *dstp,
+			       const struct cpumask *src1p,
+			       const struct cpumask *src2p)
+{
+	bitmap_xor(cpumask_bits(dstp), cpumask_bits(src1p),
+				       cpumask_bits(src2p), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_andnot - *dstp = *src1p & ~*src2p
+ * @dstp: the cpumask result
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline void cpumask_andnot(struct cpumask *dstp,
+				  const struct cpumask *src1p,
+				  const struct cpumask *src2p)
+{
+	bitmap_andnot(cpumask_bits(dstp), cpumask_bits(src1p),
+					  cpumask_bits(src2p), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_complement - *dstp = ~*srcp
+ * @dstp: the cpumask result
+ * @srcp: the input to invert
+ */
+static inline void cpumask_complement(struct cpumask *dstp,
+				      const struct cpumask *srcp)
+{
+	bitmap_complement(cpumask_bits(dstp), cpumask_bits(srcp),
+					      nr_cpumask_bits);
+}
+
+/**
+ * cpumask_equal - *src1p == *src2p
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline bool cpumask_equal(const struct cpumask *src1p,
+				const struct cpumask *src2p)
+{
+	return bitmap_equal(cpumask_bits(src1p), cpumask_bits(src2p),
+						 nr_cpumask_bits);
+}
+
+/**
+ * cpumask_intersects - (*src1p & *src2p) != 0
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline bool cpumask_intersects(const struct cpumask *src1p,
+				     const struct cpumask *src2p)
+{
+	return bitmap_intersects(cpumask_bits(src1p), cpumask_bits(src2p),
+						      nr_cpumask_bits);
+}
+
+/**
+ * cpumask_subset - (*src1p & ~*src2p) == 0
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline int cpumask_subset(const struct cpumask *src1p,
+				 const struct cpumask *src2p)
+{
+	return bitmap_subset(cpumask_bits(src1p), cpumask_bits(src2p),
+						  nr_cpumask_bits);
+}
+
+/**
+ * cpumask_empty - *srcp == 0
+ * @srcp: the cpumask to that all cpus < nr_cpu_ids are clear.
+ */
+static inline bool cpumask_empty(const struct cpumask *srcp)
+{
+	return bitmap_empty(cpumask_bits(srcp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_full - *srcp == 0xFFFFFFFF...
+ * @srcp: the cpumask to that all cpus < nr_cpu_ids are set.
+ */
+static inline bool cpumask_full(const struct cpumask *srcp)
+{
+	return bitmap_full(cpumask_bits(srcp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_weight - Count of bits in *srcp
+ * @srcp: the cpumask to count bits (< nr_cpu_ids) in.
+ */
+static inline unsigned int cpumask_weight(const struct cpumask *srcp)
+{
+	return bitmap_weight(cpumask_bits(srcp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_shift_right - *dstp = *srcp >> n
+ * @dstp: the cpumask result
+ * @srcp: the input to shift
+ * @n: the number of bits to shift by
+ */
+static inline void cpumask_shift_right(struct cpumask *dstp,
+				       const struct cpumask *srcp, int n)
+{
+	bitmap_shift_right(cpumask_bits(dstp), cpumask_bits(srcp), n,
+					       nr_cpumask_bits);
+}
+
+/**
+ * cpumask_shift_left - *dstp = *srcp << n
+ * @dstp: the cpumask result
+ * @srcp: the input to shift
+ * @n: the number of bits to shift by
+ */
+static inline void cpumask_shift_left(struct cpumask *dstp,
+				      const struct cpumask *srcp, int n)
+{
+	bitmap_shift_left(cpumask_bits(dstp), cpumask_bits(srcp), n,
+					      nr_cpumask_bits);
+}
+
+/**
+ * cpumask_copy - *dstp = *srcp
+ * @dstp: the result
+ * @srcp: the input cpumask
+ */
+static inline void cpumask_copy(struct cpumask *dstp,
+				const struct cpumask *srcp)
+{
+	bitmap_copy(cpumask_bits(dstp), cpumask_bits(srcp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_any - pick a "random" cpu from *srcp
+ * @srcp: the input cpumask
+ *
+ * Returns >= nr_cpu_ids if no cpus set.
+ */
+#define cpumask_any(srcp) cpumask_first(srcp)
+
+/**
+ * cpumask_first_and - return the first cpu from *srcp1 & *srcp2
+ * @src1p: the first input
+ * @src2p: the second input
+ *
+ * Returns >= nr_cpu_ids if no cpus set in both.  See also cpumask_next_and().
+ */
+#define cpumask_first_and(src1p, src2p) cpumask_next_and(-1, (src1p), (src2p))
+
+/**
+ * cpumask_any_and - pick a "random" cpu from *mask1 & *mask2
+ * @mask1: the first input cpumask
+ * @mask2: the second input cpumask
+ *
+ * Returns >= nr_cpu_ids if no cpus set.
+ */
+#define cpumask_any_and(mask1, mask2) cpumask_first_and((mask1), (mask2))
+
+/**
+ * cpumask_of - the cpumask containing just a given cpu
+ * @cpu: the cpu (<= nr_cpu_ids)
+ */
+#define cpumask_of(cpu) (get_cpu_mask(cpu))
+
+/**
+ * to_cpumask - convert an NR_CPUS bitmap to a struct cpumask *
+ * @bitmap: the bitmap
+ *
+ * There are a few places where cpumask_var_t isn't appropriate and
+ * static cpumasks must be used (eg. very early boot), yet we don't
+ * expose the definition of 'struct cpumask'.
+ *
+ * This does the conversion, and can be used as a constant initializer.
+ */
+#define to_cpumask(bitmap)						\
+	((struct cpumask *)(1 ? (bitmap)				\
+			    : (void *)sizeof(__check_is_bitmap(bitmap))))
+
+static inline int __check_is_bitmap(const unsigned long *bitmap)
+{
+	return 1;
+}
+
+/**
+ * cpumask_size - size to allocate for a 'struct cpumask' in bytes
+ *
+ * This will eventually be a runtime variable, depending on nr_cpu_ids.
+ */
+static inline size_t cpumask_size(void)
+{
+	/* FIXME: Once all cpumask assignments are eliminated, this
+	 * can be nr_cpumask_bits */
+	return BITS_TO_LONGS(NR_CPUS) * sizeof(long);
+}
+
+/*
+ * cpumask_var_t: struct cpumask for stack usage.
+ *
+ * Oh, the wicked games we play!  In order to make kernel coding a
+ * little more difficult, we typedef cpumask_var_t to an array or a
+ * pointer: doing &mask on an array is a noop, so it still works.
+ *
+ * ie.
+ *	cpumask_var_t tmpmask;
+ *	if (!alloc_cpumask_var(&tmpmask, GFP_KERNEL))
+ *		return -ENOMEM;
+ *
+ *	  ... use 'tmpmask' like a normal struct cpumask * ...
+ *
+ *	free_cpumask_var(tmpmask);
+ */
+#ifdef CONFIG_CPUMASK_OFFSTACK
+typedef struct cpumask *cpumask_var_t;
+
+bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags);
+void alloc_bootmem_cpumask_var(cpumask_var_t *mask);
+void free_cpumask_var(cpumask_var_t mask);
+void free_bootmem_cpumask_var(cpumask_var_t mask);
+
+#else
+typedef struct cpumask cpumask_var_t[1];
+
+static inline bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags)
+{
+	return true;
+}
+
+static inline void alloc_bootmem_cpumask_var(cpumask_var_t *mask)
+{
+}
+
+static inline void free_cpumask_var(cpumask_var_t mask)
+{
+}
+
+static inline void free_bootmem_cpumask_var(cpumask_var_t mask)
+{
+}
+#endif /* CONFIG_CPUMASK_OFFSTACK */
+
+/* The pointer versions of the maps, these will become the primary versions. */
+#define cpu_possible_mask ((const struct cpumask *)&cpu_possible_map)
+#define cpu_online_mask ((const struct cpumask *)&cpu_online_map)
+#define cpu_present_mask ((const struct cpumask *)&cpu_present_map)
+#define cpu_active_mask ((const struct cpumask *)&cpu_active_map)
+
+/* It's common to want to use cpu_all_mask in struct member initializers,
+ * so it has to refer to an address rather than a pointer. */
+extern const DECLARE_BITMAP(cpu_all_bits, NR_CPUS);
+#define cpu_all_mask to_cpumask(cpu_all_bits)
+
+/* First bits of cpu_bit_bitmap are in fact unset. */
+#define cpu_none_mask to_cpumask(cpu_bit_bitmap[0])
+
+/* Wrappers for arch boot code to manipulate normally-constant masks */
+static inline void set_cpu_possible(unsigned int cpu, bool possible)
+{
+	if (possible)
+		cpumask_set_cpu(cpu, &cpu_possible_map);
+	else
+		cpumask_clear_cpu(cpu, &cpu_possible_map);
+}
+
+static inline void set_cpu_present(unsigned int cpu, bool present)
+{
+	if (present)
+		cpumask_set_cpu(cpu, &cpu_present_map);
+	else
+		cpumask_clear_cpu(cpu, &cpu_present_map);
+}
+
+static inline void set_cpu_online(unsigned int cpu, bool online)
+{
+	if (online)
+		cpumask_set_cpu(cpu, &cpu_online_map);
+	else
+		cpumask_clear_cpu(cpu, &cpu_online_map);
+}
+
+static inline void set_cpu_active(unsigned int cpu, bool active)
+{
+	if (active)
+		cpumask_set_cpu(cpu, &cpu_active_map);
+	else
+		cpumask_clear_cpu(cpu, &cpu_active_map);
+}
+
+static inline void init_cpu_present(const struct cpumask *src)
+{
+	cpumask_copy(&cpu_present_map, src);
+}
+
+static inline void init_cpu_possible(const struct cpumask *src)
+{
+	cpumask_copy(&cpu_possible_map, src);
+}
+
+static inline void init_cpu_online(const struct cpumask *src)
+{
+	cpumask_copy(&cpu_online_map, src);
+}
 #endif /* __LINUX_CPUMASK_H */
diff -r 8f6fe5d6f181 include/linux/smp.h
--- a/include/linux/smp.h	Wed Nov 05 23:12:20 2008 +1100
+++ b/include/linux/smp.h	Fri Nov 07 00:15:12 2008 +1100
@@ -64,8 +64,17 @@ extern void smp_cpus_done(unsigned int m
  * Call a function on all other processors
  */
 int smp_call_function(void(*func)(void *info), void *info, int wait);
+/* Deprecated: use smp_call_function_many() which uses a cpumask ptr. */
 int smp_call_function_mask(cpumask_t mask, void(*func)(void *info), void *info,
 				int wait);
+
+static inline void smp_call_function_many(const struct cpumask *mask,
+					  void (*func)(void *info), void *info,
+					  int wait)
+{
+	smp_call_function_mask(*mask, func, info, wait);
+}
+
 int smp_call_function_single(int cpuid, void (*func) (void *info), void *info,
 				int wait);
 void __smp_call_function_single(int cpuid, struct call_single_data *data);
diff -r 8f6fe5d6f181 include/linux/workqueue.h
--- a/include/linux/workqueue.h	Wed Nov 05 23:12:20 2008 +1100
+++ b/include/linux/workqueue.h	Fri Nov 07 00:15:12 2008 +1100
@@ -240,4 +240,12 @@ void cancel_rearming_delayed_work(struct
 	cancel_delayed_work_sync(work);
 }
 
+#ifndef CONFIG_SMP
+static inline long work_on_cpu(unsigned int cpu, long (*fn)(void *), void *arg)
+{
+	return fn(arg);
+}
+#else
+long work_on_cpu(unsigned int cpu, long (*fn)(void *), void *arg);
+#endif /* CONFIG_SMP */
 #endif
diff -r 8f6fe5d6f181 kernel/cpu.c
--- a/kernel/cpu.c	Wed Nov 05 23:12:20 2008 +1100
+++ b/kernel/cpu.c	Fri Nov 07 00:15:12 2008 +1100
@@ -499,3 +499,6 @@ const unsigned long cpu_bit_bitmap[BITS_
 #endif
 };
 EXPORT_SYMBOL_GPL(cpu_bit_bitmap);
+
+const DECLARE_BITMAP(cpu_all_bits, NR_CPUS) = CPU_BITS_ALL;
+EXPORT_SYMBOL(cpu_all_bits);
diff -r 8f6fe5d6f181 kernel/workqueue.c
--- a/kernel/workqueue.c	Wed Nov 05 23:12:20 2008 +1100
+++ b/kernel/workqueue.c	Fri Nov 07 00:15:12 2008 +1100
@@ -970,6 +970,51 @@ undo:
 	return ret;
 }
 
+#ifdef CONFIG_SMP
+struct work_for_cpu {
+	struct work_struct work;
+	long (*fn)(void *);
+	void *arg;
+	long ret;
+};
+
+static void do_work_for_cpu(struct work_struct *w)
+{
+	struct work_for_cpu *wfc = container_of(w, struct work_for_cpu, work);
+
+	wfc->ret = wfc->fn(wfc->arg);
+}
+
+/**
+ * work_on_cpu - run a function in user context on a particular cpu
+ * @cpu: the cpu to run on
+ * @fn: the function to run
+ * @arg: the function arg
+ *
+ * This will return -EINVAL in the cpu is not online, or the return value
+ * of @fn otherwise.
+ */
+long work_on_cpu(unsigned int cpu, long (*fn)(void *), void *arg)
+{
+	struct work_for_cpu wfc;
+
+	INIT_WORK(&wfc.work, do_work_for_cpu);
+	wfc.fn = fn;
+	wfc.arg = arg;
+	get_online_cpus();
+	if (unlikely(!cpu_online(cpu)))
+		wfc.ret = -EINVAL;
+	else {
+		schedule_work_on(cpu, &wfc.work);
+		flush_work(&wfc.work);
+	}
+	put_online_cpus();
+
+	return wfc.ret;
+}
+EXPORT_SYMBOL_GPL(work_on_cpu);
+#endif /* CONFIG_SMP */
+
 void __init init_workqueues(void)
 {
 	cpu_populated_map = cpu_online_map;
diff -r 8f6fe5d6f181 lib/cpumask.c
--- a/lib/cpumask.c	Wed Nov 05 23:12:20 2008 +1100
+++ b/lib/cpumask.c	Fri Nov 07 00:15:12 2008 +1100
@@ -2,6 +2,7 @@
 #include <linux/bitops.h>
 #include <linux/cpumask.h>
 #include <linux/module.h>
+#include <linux/bootmem.h>
 
 int __first_cpu(const cpumask_t *srcp)
 {
@@ -35,3 +36,80 @@ int __any_online_cpu(const cpumask_t *ma
 	return cpu;
 }
 EXPORT_SYMBOL(__any_online_cpu);
+
+/**
+ * cpumask_next_and - get the next cpu in *src1p & *src2p
+ * @n: the cpu prior to the place to search (ie. return will be > @n)
+ * @src1p: the first cpumask pointer
+ * @src2p: the second cpumask pointer
+ *
+ * Returns >= nr_cpu_ids if no further cpus set in both.
+ */
+int cpumask_next_and(int n, const struct cpumask *src1p,
+		     const struct cpumask *src2p)
+{
+	while ((n = cpumask_next(n, src1p)) < nr_cpu_ids)
+		if (cpumask_test_cpu(n, src2p))
+			break;
+	return n;
+}
+EXPORT_SYMBOL(cpumask_next_and);
+
+/**
+ * cpumask_any_but - return a "random" in a cpumask, but not this one.
+ * @mask: the cpumask to search
+ * @cpu: the cpu to ignore.
+ *
+ * Often used to find any cpu but smp_processor_id() in a mask.
+ * Returns >= nr_cpu_ids if no cpus set.
+ */
+int cpumask_any_but(const struct cpumask *mask, unsigned int cpu)
+{
+	unsigned int i;
+
+	for_each_cpu(i, mask)
+		if (i != cpu)
+			break;
+	return i;
+}
+
+/* These are not inline because of header tangles. */
+#ifdef CONFIG_CPUMASK_OFFSTACK
+bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags)
+{
+	if (likely(slab_is_available()))
+		*mask = kmalloc(cpumask_size(), flags);
+	else {
+#ifdef CONFIG_DEBUG_PER_CPU_MAPS
+		printk(KERN_ERR
+			"=> alloc_cpumask_var: kmalloc not available!\n");
+		dump_stack();
+#endif
+		*mask = NULL;
+	}
+#ifdef CONFIG_DEBUG_PER_CPU_MAPS
+	if (!*mask) {
+		printk(KERN_ERR "=> alloc_cpumask_var: failed!\n");
+		dump_stack();
+	}
+#endif
+	return *mask != NULL;
+}
+EXPORT_SYMBOL(alloc_cpumask_var);
+
+void __init alloc_bootmem_cpumask_var(cpumask_var_t *mask)
+{
+	*mask = alloc_bootmem(cpumask_size());
+}
+
+void free_cpumask_var(cpumask_var_t mask)
+{
+	kfree(mask);
+}
+EXPORT_SYMBOL(free_cpumask_var);
+
+void free_bootmem_cpumask_var(cpumask_var_t mask)
+{
+	free_bootmem((unsigned long)mask, cpumask_size());
+}
+#endif

linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflicts in
include/linux/cpumask.h and lib/cpumask.c between commit
2d3854a37e8b767a51aba38ed6d22817b0631e33 ("cpumask: introduce new API,
without changing anything") from the cpus4096 tree and commit
0c82f41da4f9a68874b584f23feca217ba4fcd62 ("cpumask:new-API-only") from
the rr tree.

These are just different versions of the same patch, so I used the rr tree
version.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] cpumask: introduce new API, without changing anything

[Ingo Molnar]

* Rusty Russell <rusty@rustcorp.com.au> wrote:

> (Tested in linux-next as well as locally.  Linus, please apply).

if this is equal to the patch that you sent me (see the git 
coordinates below), it was also stess-tested and build-coverage tested 
by me on a healthy range of x86 systems, in a range of build 
environments.

> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
> Acked-by: Mike Travis <travis@sgi.com>

Acked-by: Ingo Molnar <mingo@elte.hu>

	Ingo

-------------->

The cpus4096 git tree can be pulled from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git cpus4096

 Thanks,

	Ingo

------------------>
Rusty Russell (1):
      cpumask: introduce new API, without changing anything


 include/linux/cpumask.h   |  502 ++++++++++++++++++++++++++++++++++++++++++++-
 include/linux/smp.h       |    9 +
 include/linux/workqueue.h |    8 +
 kernel/cpu.c              |    3 +
 kernel/workqueue.c        |   45 ++++
 lib/cpumask.c             |   73 +++++++
 6 files changed, 638 insertions(+), 2 deletions(-)

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index d3219d7..c8e6661 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -5,6 +5,9 @@
  * Cpumasks provide a bitmap suitable for representing the
  * set of CPU's in a system, one bit position per CPU number.
  *
+ * The new cpumask_ ops take a "struct cpumask *"; the old ones
+ * use cpumask_t.
+ *
  * See detailed comments in the file linux/bitmap.h describing the
  * data type on which these cpumasks are based.
  *
@@ -31,7 +34,7 @@
  *       will span the entire range of NR_CPUS.
  * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  *
- * The available cpumask operations are:
+ * The obsolescent cpumask operations are:
  *
  * void cpu_set(cpu, mask)		turn on bit 'cpu' in mask
  * void cpu_clear(cpu, mask)		turn off bit 'cpu' in mask
@@ -138,7 +141,7 @@
 #include <linux/threads.h>
 #include <linux/bitmap.h>
 
-typedef struct { DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t;
+typedef struct cpumask { DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t;
 extern cpumask_t _unused_cpumask_arg_;
 
 #define cpu_set(cpu, dst) __cpu_set((cpu), &(dst))
@@ -527,4 +530,499 @@ extern cpumask_t cpu_active_map;
 #define for_each_online_cpu(cpu)   for_each_cpu_mask_nr((cpu), cpu_online_map)
 #define for_each_present_cpu(cpu)  for_each_cpu_mask_nr((cpu), cpu_present_map)
 
+/* These are the new versions of the cpumask operators: passed by pointer.
+ * The older versions will be implemented in terms of these, then deleted. */
+#define cpumask_bits(maskp) ((maskp)->bits)
+
+#if NR_CPUS <= BITS_PER_LONG
+#define CPU_BITS_ALL						\
+{								\
+	[BITS_TO_LONGS(NR_CPUS)-1] = CPU_MASK_LAST_WORD	\
+}
+
+/* This produces more efficient code. */
+#define nr_cpumask_bits	NR_CPUS
+
+#else /* NR_CPUS > BITS_PER_LONG */
+
+#define CPU_BITS_ALL						\
+{								\
+	[0 ... BITS_TO_LONGS(NR_CPUS)-2] = ~0UL,		\
+	[BITS_TO_LONGS(NR_CPUS)-1] = CPU_MASK_LAST_WORD		\
+}
+
+#define nr_cpumask_bits	nr_cpu_ids
+#endif /* NR_CPUS > BITS_PER_LONG */
+
+/* verify cpu argument to cpumask_* operators */
+static inline unsigned int cpumask_check(unsigned int cpu)
+{
+#ifdef CONFIG_DEBUG_PER_CPU_MAPS
+	WARN_ON_ONCE(cpu >= nr_cpumask_bits);
+#endif /* CONFIG_DEBUG_PER_CPU_MAPS */
+	return cpu;
+}
+
+#if NR_CPUS == 1
+/* Uniprocesor. */
+#define cpumask_first(src)		({ (void)(src); 0; })
+#define cpumask_next(n, src)		({ (void)(src); 1; })
+#define cpumask_next_zero(n, src)	({ (void)(src); 1; })
+#define cpumask_next_and(n, srcp, andp)	({ (void)(srcp), (void)(andp); 1; })
+#define cpumask_any_but(mask, cpu)	({ (void)(mask); (void)(cpu); 0; })
+
+#define for_each_cpu(cpu, mask)			\
+	for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)
+#define for_each_cpu_and(cpu, mask, and)	\
+	for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask, (void)and)
+#else
+/**
+ * cpumask_first - get the first cpu in a cpumask
+ * @srcp: the cpumask pointer
+ *
+ * Returns >= nr_cpu_ids if no cpus set.
+ */
+static inline unsigned int cpumask_first(const struct cpumask *srcp)
+{
+	return find_first_bit(cpumask_bits(srcp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_next - get the next cpu in a cpumask
+ * @n: the cpu prior to the place to search (ie. return will be > @n)
+ * @srcp: the cpumask pointer
+ *
+ * Returns >= nr_cpu_ids if no further cpus set.
+ */
+static inline unsigned int cpumask_next(int n, const struct cpumask *srcp)
+{
+	/* -1 is a legal arg here. */
+	if (n != -1)
+		cpumask_check(n);
+	return find_next_bit(cpumask_bits(srcp), nr_cpumask_bits, n+1);
+}
+
+/**
+ * cpumask_next_zero - get the next unset cpu in a cpumask
+ * @n: the cpu prior to the place to search (ie. return will be > @n)
+ * @srcp: the cpumask pointer
+ *
+ * Returns >= nr_cpu_ids if no further cpus unset.
+ */
+static inline unsigned int cpumask_next_zero(int n, const struct cpumask *srcp)
+{
+	/* -1 is a legal arg here. */
+	if (n != -1)
+		cpumask_check(n);
+	return find_next_zero_bit(cpumask_bits(srcp), nr_cpumask_bits, n+1);
+}
+
+int cpumask_next_and(int n, const struct cpumask *, const struct cpumask *);
+int cpumask_any_but(const struct cpumask *mask, unsigned int cpu);
+
+#define for_each_cpu(cpu, mask)				\
+	for ((cpu) = -1;				\
+		(cpu) = cpumask_next((cpu), (mask)),	\
+		(cpu) < nr_cpu_ids;)
+#define for_each_cpu_and(cpu, mask, and)				\
+	for ((cpu) = -1;						\
+		(cpu) = cpumask_next_and((cpu), (mask), (and)),		\
+		(cpu) < nr_cpu_ids;)
+#endif /* SMP */
+
+#define CPU_BITS_NONE						\
+{								\
+	[0 ... BITS_TO_LONGS(NR_CPUS)-1] = 0UL			\
+}
+
+#define CPU_BITS_CPU0						\
+{								\
+	[0] =  1UL						\
+}
+
+/**
+ * cpumask_set_cpu - set a cpu in a cpumask
+ * @cpu: cpu number (< nr_cpu_ids)
+ * @dstp: the cpumask pointer
+ */
+static inline void cpumask_set_cpu(unsigned int cpu, struct cpumask *dstp)
+{
+	set_bit(cpumask_check(cpu), cpumask_bits(dstp));
+}
+
+/**
+ * cpumask_clear_cpu - clear a cpu in a cpumask
+ * @cpu: cpu number (< nr_cpu_ids)
+ * @dstp: the cpumask pointer
+ */
+static inline void cpumask_clear_cpu(int cpu, struct cpumask *dstp)
+{
+	clear_bit(cpumask_check(cpu), cpumask_bits(dstp));
+}
+
+/**
+ * cpumask_test_cpu - test for a cpu in a cpumask
+ * @cpu: cpu number (< nr_cpu_ids)
+ * @cpumask: the cpumask pointer
+ *
+ * No static inline type checking - see Subtlety (1) above.
+ */
+#define cpumask_test_cpu(cpu, cpumask) \
+	test_bit(cpumask_check(cpu), (cpumask)->bits)
+
+/**
+ * cpumask_test_and_set_cpu - atomically test and set a cpu in a cpumask
+ * @cpu: cpu number (< nr_cpu_ids)
+ * @cpumask: the cpumask pointer
+ *
+ * test_and_set_bit wrapper for cpumasks.
+ */
+static inline int cpumask_test_and_set_cpu(int cpu, struct cpumask *cpumask)
+{
+	return test_and_set_bit(cpumask_check(cpu), cpumask_bits(cpumask));
+}
+
+/**
+ * cpumask_setall - set all cpus (< nr_cpu_ids) in a cpumask
+ * @dstp: the cpumask pointer
+ */
+static inline void cpumask_setall(struct cpumask *dstp)
+{
+	bitmap_fill(cpumask_bits(dstp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_clear - clear all cpus (< nr_cpu_ids) in a cpumask
+ * @dstp: the cpumask pointer
+ */
+static inline void cpumask_clear(struct cpumask *dstp)
+{
+	bitmap_zero(cpumask_bits(dstp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_and - *dstp = *src1p & *src2p
+ * @dstp: the cpumask result
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline void cpumask_and(struct cpumask *dstp,
+			       const struct cpumask *src1p,
+			       const struct cpumask *src2p)
+{
+	bitmap_and(cpumask_bits(dstp), cpumask_bits(src1p),
+				       cpumask_bits(src2p), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_or - *dstp = *src1p | *src2p
+ * @dstp: the cpumask result
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline void cpumask_or(struct cpumask *dstp, const struct cpumask *src1p,
+			      const struct cpumask *src2p)
+{
+	bitmap_or(cpumask_bits(dstp), cpumask_bits(src1p),
+				      cpumask_bits(src2p), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_xor - *dstp = *src1p ^ *src2p
+ * @dstp: the cpumask result
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline void cpumask_xor(struct cpumask *dstp,
+			       const struct cpumask *src1p,
+			       const struct cpumask *src2p)
+{
+	bitmap_xor(cpumask_bits(dstp), cpumask_bits(src1p),
+				       cpumask_bits(src2p), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_andnot - *dstp = *src1p & ~*src2p
+ * @dstp: the cpumask result
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline void cpumask_andnot(struct cpumask *dstp,
+				  const struct cpumask *src1p,
+				  const struct cpumask *src2p)
+{
+	bitmap_andnot(cpumask_bits(dstp), cpumask_bits(src1p),
+					  cpumask_bits(src2p), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_complement - *dstp = ~*srcp
+ * @dstp: the cpumask result
+ * @srcp: the input to invert
+ */
+static inline void cpumask_complement(struct cpumask *dstp,
+				      const struct cpumask *srcp)
+{
+	bitmap_complement(cpumask_bits(dstp), cpumask_bits(srcp),
+					      nr_cpumask_bits);
+}
+
+/**
+ * cpumask_equal - *src1p == *src2p
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline bool cpumask_equal(const struct cpumask *src1p,
+				const struct cpumask *src2p)
+{
+	return bitmap_equal(cpumask_bits(src1p), cpumask_bits(src2p),
+						 nr_cpumask_bits);
+}
+
+/**
+ * cpumask_intersects - (*src1p & *src2p) != 0
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline bool cpumask_intersects(const struct cpumask *src1p,
+				     const struct cpumask *src2p)
+{
+	return bitmap_intersects(cpumask_bits(src1p), cpumask_bits(src2p),
+						      nr_cpumask_bits);
+}
+
+/**
+ * cpumask_subset - (*src1p & ~*src2p) == 0
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline int cpumask_subset(const struct cpumask *src1p,
+				 const struct cpumask *src2p)
+{
+	return bitmap_subset(cpumask_bits(src1p), cpumask_bits(src2p),
+						  nr_cpumask_bits);
+}
+
+/**
+ * cpumask_empty - *srcp == 0
+ * @srcp: the cpumask to that all cpus < nr_cpu_ids are clear.
+ */
+static inline bool cpumask_empty(const struct cpumask *srcp)
+{
+	return bitmap_empty(cpumask_bits(srcp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_full - *srcp == 0xFFFFFFFF...
+ * @srcp: the cpumask to that all cpus < nr_cpu_ids are set.
+ */
+static inline bool cpumask_full(const struct cpumask *srcp)
+{
+	return bitmap_full(cpumask_bits(srcp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_weight - Count of bits in *srcp
+ * @srcp: the cpumask to count bits (< nr_cpu_ids) in.
+ */
+static inline unsigned int cpumask_weight(const struct cpumask *srcp)
+{
+	return bitmap_weight(cpumask_bits(srcp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_shift_right - *dstp = *srcp >> n
+ * @dstp: the cpumask result
+ * @srcp: the input to shift
+ * @n: the number of bits to shift by
+ */
+static inline void cpumask_shift_right(struct cpumask *dstp,
+				       const struct cpumask *srcp, int n)
+{
+	bitmap_shift_right(cpumask_bits(dstp), cpumask_bits(srcp), n,
+					       nr_cpumask_bits);
+}
+
+/**
+ * cpumask_shift_left - *dstp = *srcp << n
+ * @dstp: the cpumask result
+ * @srcp: the input to shift
+ * @n: the number of bits to shift by
+ */
+static inline void cpumask_shift_left(struct cpumask *dstp,
+				      const struct cpumask *srcp, int n)
+{
+	bitmap_shift_left(cpumask_bits(dstp), cpumask_bits(srcp), n,
+					      nr_cpumask_bits);
+}
+
+/**
+ * cpumask_copy - *dstp = *srcp
+ * @dstp: the result
+ * @srcp: the input cpumask
+ */
+static inline void cpumask_copy(struct cpumask *dstp,
+				const struct cpumask *srcp)
+{
+	bitmap_copy(cpumask_bits(dstp), cpumask_bits(srcp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_any - pick a "random" cpu from *srcp
+ * @srcp: the input cpumask
+ *
+ * Returns >= nr_cpu_ids if no cpus set.
+ */
+#define cpumask_any(srcp) cpumask_first(srcp)
+
+/**
+ * cpumask_first_and - return the first cpu from *srcp1 & *srcp2
+ * @src1p: the first input
+ * @src2p: the second input
+ *
+ * Returns >= nr_cpu_ids if no cpus set in both.  See also cpumask_next_and().
+ */
+#define cpumask_first_and(src1p, src2p) cpumask_next_and(-1, (src1p), (src2p))
+
+/**
+ * cpumask_any_and - pick a "random" cpu from *mask1 & *mask2
+ * @mask1: the first input cpumask
+ * @mask2: the second input cpumask
+ *
+ * Returns >= nr_cpu_ids if no cpus set.
+ */
+#define cpumask_any_and(mask1, mask2) cpumask_first_and((mask1), (mask2))
+
+/**
+ * to_cpumask - convert an NR_CPUS bitmap to a struct cpumask *
+ * @bitmap: the bitmap
+ *
+ * There are a few places where cpumask_var_t isn't appropriate and
+ * static cpumasks must be used (eg. very early boot), yet we don't
+ * expose the definition of 'struct cpumask'.
+ *
+ * This does the conversion, and can be used as a constant initializer.
+ */
+#define to_cpumask(bitmap)						\
+	((struct cpumask *)(1 ? (bitmap)				\
+			    : (void *)sizeof(__check_is_bitmap(bitmap))))
+
+static inline int __check_is_bitmap(const unsigned long *bitmap)
+{
+	return 1;
+}
+
+/**
+ * cpumask_size - size to allocate for a 'struct cpumask' in bytes
+ *
+ * This will eventually be a runtime variable, depending on nr_cpu_ids.
+ */
+static inline size_t cpumask_size(void)
+{
+	/* FIXME: Once all cpumask assignments are eliminated, this
+	 * can be nr_cpumask_bits */
+	return BITS_TO_LONGS(NR_CPUS) * sizeof(long);
+}
+
+/*
+ * cpumask_var_t: struct cpumask for stack usage.
+ *
+ * Oh, the wicked games we play!  In order to make kernel coding a
+ * little more difficult, we typedef cpumask_var_t to an array or a
+ * pointer: doing &mask on an array is a noop, so it still works.
+ *
+ * ie.
+ *	cpumask_var_t tmpmask;
+ *	if (!alloc_cpumask_var(&tmpmask, GFP_KERNEL))
+ *		return -ENOMEM;
+ *
+ *	  ... use 'tmpmask' like a normal struct cpumask * ...
+ *
+ *	free_cpumask_var(tmpmask);
+ */
+#ifdef CONFIG_CPUMASK_OFFSTACK
+typedef struct cpumask *cpumask_var_t;
+
+bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags);
+void alloc_bootmem_cpumask_var(cpumask_var_t *mask);
+void free_cpumask_var(cpumask_var_t mask);
+
+#else
+typedef struct cpumask cpumask_var_t[1];
+
+static inline bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags)
+{
+	return true;
+}
+
+static inline void alloc_bootmem_cpumask_var(cpumask_var_t *mask)
+{
+}
+
+static inline void free_cpumask_var(cpumask_var_t mask)
+{
+}
+#endif /* CONFIG_CPUMASK_OFFSTACK */
+
+/* The pointer versions of the maps, these will become the primary versions. */
+#define cpu_possible_mask ((const struct cpumask *)&cpu_possible_map)
+#define cpu_online_mask ((const struct cpumask *)&cpu_online_map)
+#define cpu_present_mask ((const struct cpumask *)&cpu_present_map)
+#define cpu_active_mask ((const struct cpumask *)&cpu_active_map)
+
+/* It's common to want to use cpu_all_mask in struct member initializers,
+ * so it has to refer to an address rather than a pointer. */
+extern const DECLARE_BITMAP(cpu_all_bits, NR_CPUS);
+#define cpu_all_mask to_cpumask(cpu_all_bits)
+
+/* First bits of cpu_bit_bitmap are in fact unset. */
+#define cpu_none_mask to_cpumask(cpu_bit_bitmap[0])
+
+/* Wrappers for arch boot code to manipulate normally-constant masks */
+static inline void set_cpu_possible(unsigned int cpu, bool possible)
+{
+	if (possible)
+		cpumask_set_cpu(cpu, &cpu_possible_map);
+	else
+		cpumask_clear_cpu(cpu, &cpu_possible_map);
+}
+
+static inline void set_cpu_present(unsigned int cpu, bool present)
+{
+	if (present)
+		cpumask_set_cpu(cpu, &cpu_present_map);
+	else
+		cpumask_clear_cpu(cpu, &cpu_present_map);
+}
+
+static inline void set_cpu_online(unsigned int cpu, bool online)
+{
+	if (online)
+		cpumask_set_cpu(cpu, &cpu_online_map);
+	else
+		cpumask_clear_cpu(cpu, &cpu_online_map);
+}
+
+static inline void set_cpu_active(unsigned int cpu, bool active)
+{
+	if (active)
+		cpumask_set_cpu(cpu, &cpu_active_map);
+	else
+		cpumask_clear_cpu(cpu, &cpu_active_map);
+}
+
+static inline void init_cpu_present(const struct cpumask *src)
+{
+	cpumask_copy(&cpu_present_map, src);
+}
+
+static inline void init_cpu_possible(const struct cpumask *src)
+{
+	cpumask_copy(&cpu_possible_map, src);
+}
+
+static inline void init_cpu_online(const struct cpumask *src)
+{
+	cpumask_copy(&cpu_online_map, src);
+}
 #endif /* __LINUX_CPUMASK_H */
diff --git a/include/linux/smp.h b/include/linux/smp.h
index 2e4d58b..3f9a600 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -64,8 +64,17 @@ extern void smp_cpus_done(unsigned int max_cpus);
  * Call a function on all other processors
  */
 int smp_call_function(void(*func)(void *info), void *info, int wait);
+/* Deprecated: use smp_call_function_many() which uses a cpumask ptr. */
 int smp_call_function_mask(cpumask_t mask, void(*func)(void *info), void *info,
 				int wait);
+
+static inline void smp_call_function_many(const struct cpumask *mask,
+					  void (*func)(void *info), void *info,
+					  int wait)
+{
+	smp_call_function_mask(*mask, func, info, wait);
+}
+
 int smp_call_function_single(int cpuid, void (*func) (void *info), void *info,
 				int wait);
 void __smp_call_function_single(int cpuid, struct call_single_data *data);
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 89a5a12..b362911 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -240,4 +240,12 @@ void cancel_rearming_delayed_work(struct delayed_work *work)
 	cancel_delayed_work_sync(work);
 }
 
+#ifndef CONFIG_SMP
+static inline long work_on_cpu(unsigned int cpu, long (*fn)(void *), void *arg)
+{
+	return fn(arg);
+}
+#else
+long work_on_cpu(unsigned int cpu, long (*fn)(void *), void *arg);
+#endif /* CONFIG_SMP */
 #endif
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 86d4904..5a732c5 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -499,3 +499,6 @@ const unsigned long cpu_bit_bitmap[BITS_PER_LONG+1][BITS_TO_LONGS(NR_CPUS)] = {
 #endif
 };
 EXPORT_SYMBOL_GPL(cpu_bit_bitmap);
+
+const DECLARE_BITMAP(cpu_all_bits, NR_CPUS) = CPU_BITS_ALL;
+EXPORT_SYMBOL(cpu_all_bits);
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index f928f2a..d4dc69d 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -970,6 +970,51 @@ undo:
 	return ret;
 }
 
+#ifdef CONFIG_SMP
+struct work_for_cpu {
+	struct work_struct work;
+	long (*fn)(void *);
+	void *arg;
+	long ret;
+};
+
+static void do_work_for_cpu(struct work_struct *w)
+{
+	struct work_for_cpu *wfc = container_of(w, struct work_for_cpu, work);
+
+	wfc->ret = wfc->fn(wfc->arg);
+}
+
+/**
+ * work_on_cpu - run a function in user context on a particular cpu
+ * @cpu: the cpu to run on
+ * @fn: the function to run
+ * @arg: the function arg
+ *
+ * This will return -EINVAL in the cpu is not online, or the return value
+ * of @fn otherwise.
+ */
+long work_on_cpu(unsigned int cpu, long (*fn)(void *), void *arg)
+{
+	struct work_for_cpu wfc;
+
+	INIT_WORK(&wfc.work, do_work_for_cpu);
+	wfc.fn = fn;
+	wfc.arg = arg;
+	get_online_cpus();
+	if (unlikely(!cpu_online(cpu)))
+		wfc.ret = -EINVAL;
+	else {
+		schedule_work_on(cpu, &wfc.work);
+		flush_work(&wfc.work);
+	}
+	put_online_cpus();
+
+	return wfc.ret;
+}
+EXPORT_SYMBOL_GPL(work_on_cpu);
+#endif /* CONFIG_SMP */
+
 void __init init_workqueues(void)
 {
 	cpu_populated_map = cpu_online_map;
diff --git a/lib/cpumask.c b/lib/cpumask.c
index 5f97dc2..5ceb421 100644
--- a/lib/cpumask.c
+++ b/lib/cpumask.c
@@ -2,6 +2,7 @@
 #include <linux/bitops.h>
 #include <linux/cpumask.h>
 #include <linux/module.h>
+#include <linux/bootmem.h>
 
 int __first_cpu(const cpumask_t *srcp)
 {
@@ -35,3 +36,75 @@ int __any_online_cpu(const cpumask_t *mask)
 	return cpu;
 }
 EXPORT_SYMBOL(__any_online_cpu);
+
+/**
+ * cpumask_next_and - get the next cpu in *src1p & *src2p
+ * @n: the cpu prior to the place to search (ie. return will be > @n)
+ * @src1p: the first cpumask pointer
+ * @src2p: the second cpumask pointer
+ *
+ * Returns >= nr_cpu_ids if no further cpus set in both.
+ */
+int cpumask_next_and(int n, const struct cpumask *src1p,
+		     const struct cpumask *src2p)
+{
+	while ((n = cpumask_next(n, src1p)) < nr_cpu_ids)
+		if (cpumask_test_cpu(n, src2p))
+			break;
+	return n;
+}
+EXPORT_SYMBOL(cpumask_next_and);
+
+/**
+ * cpumask_any_but - return a "random" in a cpumask, but not this one.
+ * @mask: the cpumask to search
+ * @cpu: the cpu to ignore.
+ *
+ * Often used to find any cpu but smp_processor_id() in a mask.
+ * Returns >= nr_cpu_ids if no cpus set.
+ */
+int cpumask_any_but(const struct cpumask *mask, unsigned int cpu)
+{
+	unsigned int i;
+
+	for_each_cpu(i, mask)
+		if (i != cpu)
+			break;
+	return i;
+}
+
+/* These are not inline because of header tangles. */
+#ifdef CONFIG_CPUMASK_OFFSTACK
+bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags)
+{
+	if (likely(slab_is_available()))
+		*mask = kmalloc(cpumask_size(), flags);
+	else {
+#ifdef CONFIG_DEBUG_PER_CPU_MAPS
+		printk(KERN_ERR
+			"=> alloc_cpumask_var: kmalloc not available!\n");
+		dump_stack();
+#endif
+		*mask = NULL;
+	}
+#ifdef CONFIG_DEBUG_PER_CPU_MAPS
+	if (!*mask) {
+		printk(KERN_ERR "=> alloc_cpumask_var: failed!\n");
+		dump_stack();
+	}
+#endif
+	return *mask != NULL;
+}
+EXPORT_SYMBOL(alloc_cpumask_var);
+
+void __init alloc_bootmem_cpumask_var(cpumask_var_t *mask)
+{
+	*mask = alloc_bootmem(cpumask_size());
+}
+
+void free_cpumask_var(cpumask_var_t mask)
+{
+	kfree(mask);
+}
+EXPORT_SYMBOL(free_cpumask_var);
+#endif

Re: [PATCH] cpumask: introduce new API, without changing anything

[Andrew Morton]

On Fri, 7 Nov 2008 09:40:16 +0100 Ingo Molnar <mingo@elte.hu> wrote:

> +#if NR_CPUS == 1
> +/* Uniprocesor. */
> +#define cpumask_first(src)		({ (void)(src); 0; })
>
> ...
>
> +#else
> +static inline unsigned int cpumask_first(const struct cpumask *srcp)
> +{
> +	return find_first_bit(cpumask_bits(srcp), nr_cpumask_bits);
> +}
>
> ...
>
> +#endif /* SMP */

So I can happily compile and run

	cpumask_first("hello, world");

with CONFIG_SMP=n?

Re: [PATCH] cpumask: introduce new API, without changing anything

[Ingo Molnar]

* Andrew Morton <akpm@linux-foundation.org> wrote:

> > +#if NR_CPUS == 1
> > +/* Uniprocesor. */

btw: s/Uniprocesor/Uniprocessor

> > +#define cpumask_first(src)		({ (void)(src); 0; })
> >
> > ...
> >
> > +#else
> > +static inline unsigned int cpumask_first(const struct cpumask *srcp)
> > +{
> > +	return find_first_bit(cpumask_bits(srcp), nr_cpumask_bits);
> > +}
> >
> > ...
> >
> > +#endif /* SMP */
> 
> So I can happily compile and run
> 
> 	cpumask_first("hello, world");
> 
> with CONFIG_SMP=n?

yeah, you are right that the use of a macro sucks there, it should be 
an inline function.

We should stop using CPP, which is the outdated tech of the sixties. 
We should go with the new wave of the seventies and use this shiny new 
"C" language that's all the rage with features like type checking and 
stuff.

	Ingo

Re: [PATCH] cpumask: introduce new API, without changing anything

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 547 bytes --]

Hi Ingo,

On Fri, 7 Nov 2008 09:40:16 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> if this is equal to the patch that you sent me (see the git 
> coordinates below), it was also stess-tested and build-coverage tested 
> by me on a healthy range of x86 systems, in a range of build 
> environments.

It isn't identical.  See my message about a small merge conflict between
the cpus4096 tree and the rr tree in linux-next today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] cpumask: introduce new API, without changing anything

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Ingo,
> 
> On Fri, 7 Nov 2008 09:40:16 +0100 Ingo Molnar <mingo@elte.hu> wrote:
> >
> > if this is equal to the patch that you sent me (see the git 
> > coordinates below), it was also stess-tested and build-coverage tested 
> > by me on a healthy range of x86 systems, in a range of build 
> > environments.
> 
> It isn't identical.  See my message about a small merge conflict 
> between the cpus4096 tree and the rr tree in linux-next today.

but the change was not due to some merge conflict, it was a change 
done to the patch itself.

The merge conflict happened because Rusty iterated the patch in a 
non-append manner so two versions of the same patch collided in 
linux-next.

So ... what was the change, was it _really_ tested as-is in the 
linux-next tree for a longer time, or just merged a couple of hours 
ago?

Rusty, i pointed it out before, this kind of workflow you use in the 
rr tree is really inefficient for such types of changes. You destroy 
testing results by rebasing all the time, you make changes harder to 
review and as an end result you make it harder to achieve a better end 
result.

	Ingo

Re: [PATCH] cpumask: introduce new API, without changing anything

[Rusty Russell]

On Friday 07 November 2008 19:52:29 Andrew Morton wrote:
> So I can happily compile and run
>
> 	cpumask_first("hello, world");
>
> with CONFIG_SMP=n?

Good point.  It was based on the existing "first_cpu", but it's not a practice
we should encourage.

Hmm, the implementation of these UP versions is wrong in corner cases, too. 
Obviously it doesn't currently matter the way they are used, but a nasty trap
for the future.

Here's the addition, I've queued it for linux-next (which will next come out
after the weekend).

diff -u b/include/linux/cpumask.h b/include/linux/cpumask.h
--- b/include/linux/cpumask.h	Fri Nov 07 00:15:12 2008 +1100
+++ b/include/linux/cpumask.h	Fri Nov 07 22:28:33 2008 +1100
@@ -564,12 +564,36 @@
 }
 
 #if NR_CPUS == 1
-/* Uniprocesor. */
-#define cpumask_first(src)		({ (void)(src); 0; })
-#define cpumask_next(n, src)		({ (void)(src); 1; })
-#define cpumask_next_zero(n, src)	({ (void)(src); 1; })
-#define cpumask_next_and(n, srcp, andp)	({ (void)(srcp), (void)(andp); 1; })
-#define cpumask_any_but(mask, cpu)	({ (void)(mask); (void)(cpu); 0; })
+/* Uniprocessor.  Assume all masks are "1". */
+static inline unsigned int cpumask_first(const struct cpumask *srcp)
+{
+	return 0;
+}
+
+/* Valid inputs for n are -1 and 0. */
+static inline unsigned int cpumask_next(int n, const struct cpumask *srcp)
+{
+	return n+1;
+}
+
+static inline unsigned int cpumask_next_zero(int n, const struct cpumask *srcp)
+{
+	return n+1;
+}
+
+static inline unsigned int cpumask_next_and(int n,
+					    const struct cpumask *srcp,
+					    const struct cpumask *andp)
+{
+	return n+1;
+}
+
+/* cpu must be a valid cpu, ie 0, so there's no other choice. */
+static inline unsigned int cpumask_any_but(const struct cpumask *mask,
+					   unsigned int cpu)
+{
+	return 1;
+}
 
 #define for_each_cpu(cpu, mask)			\
 	for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)
diff -u b/lib/cpumask.c b/lib/cpumask.c
--- b/lib/cpumask.c	Fri Nov 07 00:15:12 2008 +1100
+++ b/lib/cpumask.c	Fri Nov 07 22:28:33 2008 +1100
@@ -67,6 +67,7 @@
 {
 	unsigned int i;
 
+	cpumask_check(cpu);
 	for_each_cpu(i, mask)
 		if (i != cpu)
 			break;

Re: [PATCH] cpumask: introduce new API, without changing anything

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> but the change was not due to some merge conflict, it was a change 
> done to the patch itself.
> 
> The merge conflict happened because Rusty iterated the patch in a 
> non-append manner so two versions of the same patch collided in 
> linux-next.
> 
> So ... what was the change, was it _really_ tested as-is in the 
> linux-next tree for a longer time, or just merged a couple of hours 
> ago?

hm, i just researched it a bit, and the patch Rusty just submitted to 
Linus was not in linux-next it appears, as the modified commit is just 
a few hours old.

Find below the delta patch between the two versions, and an 
analysis/review of the changes. I've started testing it as well, and 
it's looking good so far.

Here is when the new version showed up in linux-next a few hours ago:

| commit 92a8334f1b0ad1f65127bc763ab214d6b60ec966
| Author:     Stephen Rothwell <sfr@canb.auug.org.au>
| AuthorDate: Fri Nov 7 20:44:35 2008 +1100
| Commit:     Stephen Rothwell <sfr@canb.auug.org.au>
| CommitDate: Fri Nov 7 20:44:35 2008 +1100
|
|    Add linux-next specific files for 20081107

It was a new (and modified) quilt-exported commit from "quilt/rr":

| 0c82f41: cpumask:new-API-only
|
| Author:     Rusty Russell <rusty@rustcorp.com.au>
| AuthorDate: Fri Nov 7 11:12:29 2008 +1100
| Commit:     Stephen Rothwell <sfr@canb.auug.org.au>
| CommitDate: Fri Nov 7 11:12:29 2008 +1100

Which collided with a previous version of that patch in the cpus4096 
tree:

| 2d3854a: cpumask: introduce new API, without changing anything
|
| Author:     Rusty Russell <rusty@rustcorp.com.au>
| AuthorDate: Wed Nov 5 13:39:10 2008 +1100
| CommitDate: Thu Nov 6 09:05:33 2008 +0100

"0c82f41: cpumask:new-API-only" thus has only a couple of hours of 
lifetime and the "this has been in linux-next" is only true for that 
short time period.

So ... i've reconstructed what's new in 0c82f41, and i came up with 
the delta patch below.

Review of the delta patch:

- the cpumask_of() is added to the SMP section of cpumask.h but not to
  the UP section. Similarly, some of the other SMP APIs are not 
  declared in the UP section either. (Furthermore, the macros in the 
  UP section should really be inlines, not macros - as akpm noticed it
  too.)

- the free_bootmem_cpumask_var() addition looks good but is a tiny bit
  incomplete: the free_bootmem_cpumask_var() function should be marked 
  __init, like all bootmem methods are.

i guess these changes should be OK.

Note that such types of minor problems are very easy to spot and 
address in an append-only workflow (even if you just emulate it in 
quilt), but are hidden and laborous to extract with an agreesive 
quilt-rebasing history-eating workflow that just exports completely 
new versions of patches.

Just in case you are wondering why i care so much about 'your' patch: 
i'd like it to go upstream. The patch and the plan affects subsystems 
i'm (co-)maintaining, in a nontrivial way, (scheduler, irq and x86 
code), and the cpumask code caused trouble in the past so i'd like to 
know _exactly_ what future changes go into it. Isnt that a fair 
interest?

But your "rr tree" is not suitable at all to follow the development of 
this effort. Deltas are not transparent and reviewable, the changes 
are mixed into other changes and you force me into this kind of review 
and delta patch forensics and that is very inefficient - and it 
obviously harms the end result and wastes time for no good reason.

And yes, when all is said and done and everyone's happy there's no 
problem with eventually collapsing delta patches together into a 
single clean patch.

Most of the time it's not _worth_ touching existing history with 
folding patches: as you can see it from the patch below, there's no 
technical reason why it could not have been a separate delta patch. 
Those changes do not cause _any_ bisection barrier, nor do they cause 
any other of problem either.

And dont get me wrong, destroying the delta was not malice on your 
part in any way, it was "just" a side-effect destruction of 
information that resulted out of your customary work flow. I realize 
that you like and prefer that workflow, and that you have used it for 
years, but you should also accept it when i point out the problems 
that it causes down the line.

And the thing is, a year ago i was in similar shoes and i was on the 
receiving end of similar complaints, and in hindsight i do not regret 
at all having changed to a Git workflow =B-)

	Ingo

----------------->
>From cd83e42c6b0413dcbb548c2ead799111ff7e6a13 Mon Sep 17 00:00:00 2001
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Fri, 7 Nov 2008 11:12:29 +1100
Subject: [PATCH] cpumask: new API, v2

- add cpumask_of()
- add free_bootmem_cpumask_var()

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 include/linux/cpumask.h |   11 +++++++++++
 lib/cpumask.c           |    5 +++++
 2 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index c8e6661..31caa1b 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -894,6 +894,12 @@ static inline void cpumask_copy(struct cpumask *dstp,
 #define cpumask_any_and(mask1, mask2) cpumask_first_and((mask1), (mask2))
 
 /**
+ * cpumask_of - the cpumask containing just a given cpu
+ * @cpu: the cpu (<= nr_cpu_ids)
+ */
+#define cpumask_of(cpu) (get_cpu_mask(cpu))
+
+/**
  * to_cpumask - convert an NR_CPUS bitmap to a struct cpumask *
  * @bitmap: the bitmap
  *
@@ -946,6 +952,7 @@ typedef struct cpumask *cpumask_var_t;
 bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags);
 void alloc_bootmem_cpumask_var(cpumask_var_t *mask);
 void free_cpumask_var(cpumask_var_t mask);
+void free_bootmem_cpumask_var(cpumask_var_t mask);
 
 #else
 typedef struct cpumask cpumask_var_t[1];
@@ -962,6 +969,10 @@ static inline void alloc_bootmem_cpumask_var(cpumask_var_t *mask)
 static inline void free_cpumask_var(cpumask_var_t mask)
 {
 }
+
+static inline void free_bootmem_cpumask_var(cpumask_var_t mask)
+{
+}
 #endif /* CONFIG_CPUMASK_OFFSTACK */
 
 /* The pointer versions of the maps, these will become the primary versions. */
diff --git a/lib/cpumask.c b/lib/cpumask.c
index 5ceb421..2ebc3a9 100644
--- a/lib/cpumask.c
+++ b/lib/cpumask.c
@@ -107,4 +107,9 @@ void free_cpumask_var(cpumask_var_t mask)
 	kfree(mask);
 }
 EXPORT_SYMBOL(free_cpumask_var);
+
+void free_bootmem_cpumask_var(cpumask_var_t mask)
+{
+	free_bootmem((unsigned long)mask, cpumask_size());
+}
 #endif

Re: [PATCH] cpumask: introduce new API, without changing anything

[Mike Travis]

Ingo Molnar wrote:
...
> Find below the delta patch between the two versions, and an 
> analysis/review of the changes. I've started testing it as well, and 
> it's looking good so far.
> 
...
> "0c82f41: cpumask:new-API-only" thus has only a couple of hours of 
> lifetime and the "this has been in linux-next" is only true for that 
> short time period.
> 
> So ... i've reconstructed what's new in 0c82f41, and i came up with 
> the delta patch below.
...
>>From cd83e42c6b0413dcbb548c2ead799111ff7e6a13 Mon Sep 17 00:00:00 2001
> From: Rusty Russell <rusty@rustcorp.com.au>
> Date: Fri, 7 Nov 2008 11:12:29 +1100
> Subject: [PATCH] cpumask: new API, v2
> 
> - add cpumask_of()
> - add free_bootmem_cpumask_var()
...

I'd like to begin resubmitting the patches that were in the cpus4096-v2
branch but I'm not quite sure how to set up the git tree.  I have:

git-remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git-remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
git-remote update
git-checkout -b cpus4096 tip/cpus4096

But I don't see the linux-next changes (like cpumask_first for uniprocessor), so I'm
guessing I need to either merge in linux-next, or insert it into the above setup
commands?

Fyi, hopefully this patch submission conduit will work:

	generic only: via linux-next
	arch-specific (x86 + others): Rusty via arch-maintainers (linux-next?)
	(x86 only): Mike via tip/cpus4096

Does this work for you?

Thanks,
Mike

Re: [PATCH] cpumask: introduce new API, without changing anything

[Rusty Russell]

On Friday 07 November 2008 23:24:00 Ingo Molnar wrote:
> Find below the delta patch between the two versions, and an
> analysis/review of the changes. I've started testing it as well, and
> it's looking good so far.

Ok, I sent through the latest delta on top of this before, but see below.

> - the cpumask_of() is added to the SMP section of cpumask.h but not to
>   the UP section.

Not quite: it's in the general section.  Don't scare me like that :)

> - the free_bootmem_cpumask_var() addition looks good but is a tiny bit
>   incomplete: the free_bootmem_cpumask_var() function should be marked
>   __init, like all bootmem methods are.

Looks like you took that draft I mailed around?  Mike asked for free_... as a
response to that.  But I'll fix the __init.

I've restored the patch into that version you have, plus separate updates.  I
hope that fixes the workflow issues.

Updates below for reference.

Thanks,
Rusty.
===
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -894,6 +894,12 @@ static inline void cpumask_copy(struct c
 #define cpumask_any_and(mask1, mask2) cpumask_first_and((mask1), (mask2))
 
 /**
+ * cpumask_of - the cpumask containing just a given cpu
+ * @cpu: the cpu (<= nr_cpu_ids)
+ */
+#define cpumask_of(cpu) (get_cpu_mask(cpu))
+
+/**
  * to_cpumask - convert an NR_CPUS bitmap to a struct cpumask *
  * @bitmap: the bitmap
  *
@@ -946,6 +952,7 @@ bool alloc_cpumask_var(cpumask_var_t *ma
 bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags);
 void alloc_bootmem_cpumask_var(cpumask_var_t *mask);
 void free_cpumask_var(cpumask_var_t mask);
+void free_bootmem_cpumask_var(cpumask_var_t mask);
 
 #else
 typedef struct cpumask cpumask_var_t[1];
@@ -960,6 +967,10 @@ static inline void alloc_bootmem_cpumask
 }
 
 static inline void free_cpumask_var(cpumask_var_t mask)
+{
+}
+
+static inline void free_bootmem_cpumask_var(cpumask_var_t mask)
 {
 }
 #endif /* CONFIG_CPUMASK_OFFSTACK */
diff --git a/lib/cpumask.c b/lib/cpumask.c
--- a/lib/cpumask.c
+++ b/lib/cpumask.c
@@ -107,4 +107,9 @@ void free_cpumask_var(cpumask_var_t mask
 	kfree(mask);
 }
 EXPORT_SYMBOL(free_cpumask_var);
+
+void free_bootmem_cpumask_var(cpumask_var_t mask)
+{
+	free_bootmem((unsigned long)mask, cpumask_size());
+}
 #endif
===
1) Andrew pointed out inlines are superior to macros.  Also, UP versions
   weren't correct in all cases (doesn't matter at the moment, but
   nasty surprise one day).

2) Documentation was missing for for_each_cpu and for_each_cpu_and.

3) As we state when fixing the UP version, the "cpu" arg to
   "cpumask_any_but()" must be a valid CPU number, so add debug check.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

diff -r 09f8198c811d include/linux/cpumask.h
--- a/include/linux/cpumask.h	Sat Nov 08 20:05:51 2008 +1100
+++ b/include/linux/cpumask.h	Sat Nov 08 20:10:07 2008 +1100
@@ -564,12 +564,36 @@ static inline unsigned int cpumask_check
 }
 
 #if NR_CPUS == 1
-/* Uniprocesor. */
-#define cpumask_first(src)		({ (void)(src); 0; })
-#define cpumask_next(n, src)		({ (void)(src); 1; })
-#define cpumask_next_zero(n, src)	({ (void)(src); 1; })
-#define cpumask_next_and(n, srcp, andp)	({ (void)(srcp), (void)(andp); 1; })
-#define cpumask_any_but(mask, cpu)	({ (void)(mask); (void)(cpu); 0; })
+/* Uniprocessor.  Assume all masks are "1". */
+static inline unsigned int cpumask_first(const struct cpumask *srcp)
+{
+	return 0;
+}
+
+/* Valid inputs for n are -1 and 0. */
+static inline unsigned int cpumask_next(int n, const struct cpumask *srcp)
+{
+	return n+1;
+}
+
+static inline unsigned int cpumask_next_zero(int n, const struct cpumask *srcp)
+{
+	return n+1;
+}
+
+static inline unsigned int cpumask_next_and(int n,
+					    const struct cpumask *srcp,
+					    const struct cpumask *andp)
+{
+	return n+1;
+}
+
+/* cpu must be a valid cpu, ie 0, so there's no other choice. */
+static inline unsigned int cpumask_any_but(const struct cpumask *mask,
+					   unsigned int cpu)
+{
+	return 1;
+}
 
 #define for_each_cpu(cpu, mask)			\
 	for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)
@@ -620,10 +644,32 @@ int cpumask_next_and(int n, const struct
 int cpumask_next_and(int n, const struct cpumask *, const struct cpumask *);
 int cpumask_any_but(const struct cpumask *mask, unsigned int cpu);
 
+/**
+ * for_each_cpu - iterate over every cpu in a mask
+ * @cpu: the (optionally unsigned) integer iterator
+ * @mask: the cpumask pointer
+ *
+ * After the loop, cpu is >= nr_cpu_ids.
+ */
 #define for_each_cpu(cpu, mask)				\
 	for ((cpu) = -1;				\
 		(cpu) = cpumask_next((cpu), (mask)),	\
 		(cpu) < nr_cpu_ids;)
+
+/**
+ * for_each_cpu_and - iterate over every cpu in both masks
+ * @cpu: the (optionally unsigned) integer iterator
+ * @mask: the first cpumask pointer
+ * @and: the second cpumask pointer
+ *
+ * This saves a temporary CPU mask in many places.  It is equivalent to:
+ *	struct cpumask tmp;
+ *	cpumask_and(&tmp, &mask, &and);
+ *	for_each_cpu(cpu, &tmp)
+ *		...
+ *
+ * After the loop, cpu is >= nr_cpu_ids.
+ */
 #define for_each_cpu_and(cpu, mask, and)				\
 	for ((cpu) = -1;						\
 		(cpu) = cpumask_next_and((cpu), (mask), (and)),		\
diff -r 09f8198c811d lib/cpumask.c
--- a/lib/cpumask.c	Sat Nov 08 20:05:51 2008 +1100
+++ b/lib/cpumask.c	Sat Nov 08 20:10:07 2008 +1100
@@ -67,6 +67,7 @@ int cpumask_any_but(const struct cpumask
 {
 	unsigned int i;
 
+	cpumask_check(cpu);
 	for_each_cpu(i, mask)
 		if (i != cpu)
 			break;
===
Ingo points out that free_bootmem_cpumask_var() should be __init.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

diff -r dfda8a1507d5 lib/cpumask.c
--- a/lib/cpumask.c	Sat Nov 08 20:10:15 2008 +1100
+++ b/lib/cpumask.c	Sat Nov 08 20:19:14 2008 +1100
@@ -109,7 +109,7 @@ void free_cpumask_var(cpumask_var_t mask
 }
 EXPORT_SYMBOL(free_cpumask_var);
 
-void free_bootmem_cpumask_var(cpumask_var_t mask)
+void __init free_bootmem_cpumask_var(cpumask_var_t mask)
 {
 	free_bootmem((unsigned long)mask, cpumask_size());
 }

Re: [PATCH] cpumask: introduce new API, without changing anything

[Ingo Molnar]

* Rusty Russell <rusty@rustcorp.com.au> wrote:

> On Friday 07 November 2008 23:24:00 Ingo Molnar wrote:
> > Find below the delta patch between the two versions, and an
> > analysis/review of the changes. I've started testing it as well, and
> > it's looking good so far.
> 
> Ok, I sent through the latest delta on top of this before, but see below.
> 
> > - the cpumask_of() is added to the SMP section of cpumask.h but not to
> >   the UP section.
> 
> Not quite: it's in the general section.  Don't scare me like that :)

heh, indeed - i looked twice and both times i missed this in the 
middle of that code:

 #endif /* SMP */

... sorry, my bad! (a newline before this line might have helped)

> > - the free_bootmem_cpumask_var() addition looks good but is a tiny bit
> >   incomplete: the free_bootmem_cpumask_var() function should be marked
> >   __init, like all bootmem methods are.
> 
> Looks like you took that draft I mailed around?  Mike asked for 
> free_... as a response to that.  But I'll fix the __init.
> 
> I've restored the patch into that version you have, plus separate 
> updates.  I hope that fixes the workflow issues.
> 
> Updates below for reference.

thanks a ton, this looks perfect.

Mike, could you please double-check that the version that is in 
tip/cpus4096 [622e0ed] is the final version you need, and that if you 
base subsequent patches on it it works as expected?

Then it would be all green and Rusty could send the final version of 
the patch to Linus. It has my ack obviously:

  Acked-by: Ingo Molnar <mingo@elte.hu>

and once that patch hits upstream, we could restructure/rebase the 
commits in cpus4096-v2 ontop of upstream and spread them out properly. 
Does that sound optimal?

Thomas also did a cross-build of it, and it looks all good:

   Run 141: 2008-11-07 13:54:41 .. 2008-11-07 15:02:59

   Run 141: 17 of 19 operations OK
   Run 141: 2 of 19 operations FAILED

   http://www.tglx.de/autoqa-logs/000141-0008-0005.log
   http://www.tglx.de/autoqa-logs/000141-0008-0015.log

the two build failures are not related to these changes.

	Ingo

Re: [PATCH] cpumask: introduce new API, without changing anything

[Linus Torvalds]

On Sat, 8 Nov 2008, Rusty Russell wrote:
> 
> Ok, I sent through the latest delta on top of this before, but see below.

Can somebody send a final patch-set to me? Right now I have multiple 
versions of patches, apparently on top of each other, and sometimes 
multiple patches per email. Very confusing, and I do _not_ want to apply 
the wrong thing by mistake.

		Linus

Re: [PATCH] cpumask: introduce new API, without changing anything

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sat, 8 Nov 2008, Rusty Russell wrote:
> > 
> > Ok, I sent through the latest delta on top of this before, but see below.
> 
> Can somebody send a final patch-set to me? Right now I have multiple 
> versions of patches, apparently on top of each other, and sometimes 
> multiple patches per email. Very confusing, and I do _not_ want to 
> apply the wrong thing by mistake.

I've got them collected and tested (and so has Rusty), see the tree 
URI below. There's no pending problem left that i know of. I also just 
did a fresh test-build and test-boot of this tree, for good measure.

	Ingo

-------------------->

the latest cpus4096 git tree can be found at:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git cpus4096

 Thanks,

	Ingo

------------------>
Rusty Russell (3):
      cpumask: introduce new API, without changing anything
      cpumask: new API, v2
      cpumask: introduce new API, without changing anything, v3


 include/linux/cpumask.h   |  559 ++++++++++++++++++++++++++++++++++++++++++++-
 include/linux/smp.h       |    9 +
 include/linux/workqueue.h |    8 +
 kernel/cpu.c              |    3 +
 kernel/workqueue.c        |   45 ++++
 lib/cpumask.c             |   79 +++++++
 6 files changed, 701 insertions(+), 2 deletions(-)

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index d3219d7..21e1dd4 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -5,6 +5,9 @@
  * Cpumasks provide a bitmap suitable for representing the
  * set of CPU's in a system, one bit position per CPU number.
  *
+ * The new cpumask_ ops take a "struct cpumask *"; the old ones
+ * use cpumask_t.
+ *
  * See detailed comments in the file linux/bitmap.h describing the
  * data type on which these cpumasks are based.
  *
@@ -31,7 +34,7 @@
  *       will span the entire range of NR_CPUS.
  * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  *
- * The available cpumask operations are:
+ * The obsolescent cpumask operations are:
  *
  * void cpu_set(cpu, mask)		turn on bit 'cpu' in mask
  * void cpu_clear(cpu, mask)		turn off bit 'cpu' in mask
@@ -138,7 +141,7 @@
 #include <linux/threads.h>
 #include <linux/bitmap.h>
 
-typedef struct { DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t;
+typedef struct cpumask { DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t;
 extern cpumask_t _unused_cpumask_arg_;
 
 #define cpu_set(cpu, dst) __cpu_set((cpu), &(dst))
@@ -527,4 +530,556 @@ extern cpumask_t cpu_active_map;
 #define for_each_online_cpu(cpu)   for_each_cpu_mask_nr((cpu), cpu_online_map)
 #define for_each_present_cpu(cpu)  for_each_cpu_mask_nr((cpu), cpu_present_map)
 
+/* These are the new versions of the cpumask operators: passed by pointer.
+ * The older versions will be implemented in terms of these, then deleted. */
+#define cpumask_bits(maskp) ((maskp)->bits)
+
+#if NR_CPUS <= BITS_PER_LONG
+#define CPU_BITS_ALL						\
+{								\
+	[BITS_TO_LONGS(NR_CPUS)-1] = CPU_MASK_LAST_WORD	\
+}
+
+/* This produces more efficient code. */
+#define nr_cpumask_bits	NR_CPUS
+
+#else /* NR_CPUS > BITS_PER_LONG */
+
+#define CPU_BITS_ALL						\
+{								\
+	[0 ... BITS_TO_LONGS(NR_CPUS)-2] = ~0UL,		\
+	[BITS_TO_LONGS(NR_CPUS)-1] = CPU_MASK_LAST_WORD		\
+}
+
+#define nr_cpumask_bits	nr_cpu_ids
+#endif /* NR_CPUS > BITS_PER_LONG */
+
+/* verify cpu argument to cpumask_* operators */
+static inline unsigned int cpumask_check(unsigned int cpu)
+{
+#ifdef CONFIG_DEBUG_PER_CPU_MAPS
+	WARN_ON_ONCE(cpu >= nr_cpumask_bits);
+#endif /* CONFIG_DEBUG_PER_CPU_MAPS */
+	return cpu;
+}
+
+#if NR_CPUS == 1
+/* Uniprocessor.  Assume all masks are "1". */
+static inline unsigned int cpumask_first(const struct cpumask *srcp)
+{
+	return 0;
+}
+
+/* Valid inputs for n are -1 and 0. */
+static inline unsigned int cpumask_next(int n, const struct cpumask *srcp)
+{
+	return n+1;
+}
+
+static inline unsigned int cpumask_next_zero(int n, const struct cpumask *srcp)
+{
+	return n+1;
+}
+
+static inline unsigned int cpumask_next_and(int n,
+					    const struct cpumask *srcp,
+					    const struct cpumask *andp)
+{
+	return n+1;
+}
+
+/* cpu must be a valid cpu, ie 0, so there's no other choice. */
+static inline unsigned int cpumask_any_but(const struct cpumask *mask,
+					   unsigned int cpu)
+{
+	return 1;
+}
+
+#define for_each_cpu(cpu, mask)			\
+	for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)
+#define for_each_cpu_and(cpu, mask, and)	\
+	for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask, (void)and)
+#else
+/**
+ * cpumask_first - get the first cpu in a cpumask
+ * @srcp: the cpumask pointer
+ *
+ * Returns >= nr_cpu_ids if no cpus set.
+ */
+static inline unsigned int cpumask_first(const struct cpumask *srcp)
+{
+	return find_first_bit(cpumask_bits(srcp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_next - get the next cpu in a cpumask
+ * @n: the cpu prior to the place to search (ie. return will be > @n)
+ * @srcp: the cpumask pointer
+ *
+ * Returns >= nr_cpu_ids if no further cpus set.
+ */
+static inline unsigned int cpumask_next(int n, const struct cpumask *srcp)
+{
+	/* -1 is a legal arg here. */
+	if (n != -1)
+		cpumask_check(n);
+	return find_next_bit(cpumask_bits(srcp), nr_cpumask_bits, n+1);
+}
+
+/**
+ * cpumask_next_zero - get the next unset cpu in a cpumask
+ * @n: the cpu prior to the place to search (ie. return will be > @n)
+ * @srcp: the cpumask pointer
+ *
+ * Returns >= nr_cpu_ids if no further cpus unset.
+ */
+static inline unsigned int cpumask_next_zero(int n, const struct cpumask *srcp)
+{
+	/* -1 is a legal arg here. */
+	if (n != -1)
+		cpumask_check(n);
+	return find_next_zero_bit(cpumask_bits(srcp), nr_cpumask_bits, n+1);
+}
+
+int cpumask_next_and(int n, const struct cpumask *, const struct cpumask *);
+int cpumask_any_but(const struct cpumask *mask, unsigned int cpu);
+
+/**
+ * for_each_cpu - iterate over every cpu in a mask
+ * @cpu: the (optionally unsigned) integer iterator
+ * @mask: the cpumask pointer
+ *
+ * After the loop, cpu is >= nr_cpu_ids.
+ */
+#define for_each_cpu(cpu, mask)				\
+	for ((cpu) = -1;				\
+		(cpu) = cpumask_next((cpu), (mask)),	\
+		(cpu) < nr_cpu_ids;)
+
+/**
+ * for_each_cpu_and - iterate over every cpu in both masks
+ * @cpu: the (optionally unsigned) integer iterator
+ * @mask: the first cpumask pointer
+ * @and: the second cpumask pointer
+ *
+ * This saves a temporary CPU mask in many places.  It is equivalent to:
+ *	struct cpumask tmp;
+ *	cpumask_and(&tmp, &mask, &and);
+ *	for_each_cpu(cpu, &tmp)
+ *		...
+ *
+ * After the loop, cpu is >= nr_cpu_ids.
+ */
+#define for_each_cpu_and(cpu, mask, and)				\
+	for ((cpu) = -1;						\
+		(cpu) = cpumask_next_and((cpu), (mask), (and)),		\
+		(cpu) < nr_cpu_ids;)
+#endif /* SMP */
+
+#define CPU_BITS_NONE						\
+{								\
+	[0 ... BITS_TO_LONGS(NR_CPUS)-1] = 0UL			\
+}
+
+#define CPU_BITS_CPU0						\
+{								\
+	[0] =  1UL						\
+}
+
+/**
+ * cpumask_set_cpu - set a cpu in a cpumask
+ * @cpu: cpu number (< nr_cpu_ids)
+ * @dstp: the cpumask pointer
+ */
+static inline void cpumask_set_cpu(unsigned int cpu, struct cpumask *dstp)
+{
+	set_bit(cpumask_check(cpu), cpumask_bits(dstp));
+}
+
+/**
+ * cpumask_clear_cpu - clear a cpu in a cpumask
+ * @cpu: cpu number (< nr_cpu_ids)
+ * @dstp: the cpumask pointer
+ */
+static inline void cpumask_clear_cpu(int cpu, struct cpumask *dstp)
+{
+	clear_bit(cpumask_check(cpu), cpumask_bits(dstp));
+}
+
+/**
+ * cpumask_test_cpu - test for a cpu in a cpumask
+ * @cpu: cpu number (< nr_cpu_ids)
+ * @cpumask: the cpumask pointer
+ *
+ * No static inline type checking - see Subtlety (1) above.
+ */
+#define cpumask_test_cpu(cpu, cpumask) \
+	test_bit(cpumask_check(cpu), (cpumask)->bits)
+
+/**
+ * cpumask_test_and_set_cpu - atomically test and set a cpu in a cpumask
+ * @cpu: cpu number (< nr_cpu_ids)
+ * @cpumask: the cpumask pointer
+ *
+ * test_and_set_bit wrapper for cpumasks.
+ */
+static inline int cpumask_test_and_set_cpu(int cpu, struct cpumask *cpumask)
+{
+	return test_and_set_bit(cpumask_check(cpu), cpumask_bits(cpumask));
+}
+
+/**
+ * cpumask_setall - set all cpus (< nr_cpu_ids) in a cpumask
+ * @dstp: the cpumask pointer
+ */
+static inline void cpumask_setall(struct cpumask *dstp)
+{
+	bitmap_fill(cpumask_bits(dstp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_clear - clear all cpus (< nr_cpu_ids) in a cpumask
+ * @dstp: the cpumask pointer
+ */
+static inline void cpumask_clear(struct cpumask *dstp)
+{
+	bitmap_zero(cpumask_bits(dstp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_and - *dstp = *src1p & *src2p
+ * @dstp: the cpumask result
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline void cpumask_and(struct cpumask *dstp,
+			       const struct cpumask *src1p,
+			       const struct cpumask *src2p)
+{
+	bitmap_and(cpumask_bits(dstp), cpumask_bits(src1p),
+				       cpumask_bits(src2p), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_or - *dstp = *src1p | *src2p
+ * @dstp: the cpumask result
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline void cpumask_or(struct cpumask *dstp, const struct cpumask *src1p,
+			      const struct cpumask *src2p)
+{
+	bitmap_or(cpumask_bits(dstp), cpumask_bits(src1p),
+				      cpumask_bits(src2p), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_xor - *dstp = *src1p ^ *src2p
+ * @dstp: the cpumask result
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline void cpumask_xor(struct cpumask *dstp,
+			       const struct cpumask *src1p,
+			       const struct cpumask *src2p)
+{
+	bitmap_xor(cpumask_bits(dstp), cpumask_bits(src1p),
+				       cpumask_bits(src2p), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_andnot - *dstp = *src1p & ~*src2p
+ * @dstp: the cpumask result
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline void cpumask_andnot(struct cpumask *dstp,
+				  const struct cpumask *src1p,
+				  const struct cpumask *src2p)
+{
+	bitmap_andnot(cpumask_bits(dstp), cpumask_bits(src1p),
+					  cpumask_bits(src2p), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_complement - *dstp = ~*srcp
+ * @dstp: the cpumask result
+ * @srcp: the input to invert
+ */
+static inline void cpumask_complement(struct cpumask *dstp,
+				      const struct cpumask *srcp)
+{
+	bitmap_complement(cpumask_bits(dstp), cpumask_bits(srcp),
+					      nr_cpumask_bits);
+}
+
+/**
+ * cpumask_equal - *src1p == *src2p
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline bool cpumask_equal(const struct cpumask *src1p,
+				const struct cpumask *src2p)
+{
+	return bitmap_equal(cpumask_bits(src1p), cpumask_bits(src2p),
+						 nr_cpumask_bits);
+}
+
+/**
+ * cpumask_intersects - (*src1p & *src2p) != 0
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline bool cpumask_intersects(const struct cpumask *src1p,
+				     const struct cpumask *src2p)
+{
+	return bitmap_intersects(cpumask_bits(src1p), cpumask_bits(src2p),
+						      nr_cpumask_bits);
+}
+
+/**
+ * cpumask_subset - (*src1p & ~*src2p) == 0
+ * @src1p: the first input
+ * @src2p: the second input
+ */
+static inline int cpumask_subset(const struct cpumask *src1p,
+				 const struct cpumask *src2p)
+{
+	return bitmap_subset(cpumask_bits(src1p), cpumask_bits(src2p),
+						  nr_cpumask_bits);
+}
+
+/**
+ * cpumask_empty - *srcp == 0
+ * @srcp: the cpumask to that all cpus < nr_cpu_ids are clear.
+ */
+static inline bool cpumask_empty(const struct cpumask *srcp)
+{
+	return bitmap_empty(cpumask_bits(srcp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_full - *srcp == 0xFFFFFFFF...
+ * @srcp: the cpumask to that all cpus < nr_cpu_ids are set.
+ */
+static inline bool cpumask_full(const struct cpumask *srcp)
+{
+	return bitmap_full(cpumask_bits(srcp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_weight - Count of bits in *srcp
+ * @srcp: the cpumask to count bits (< nr_cpu_ids) in.
+ */
+static inline unsigned int cpumask_weight(const struct cpumask *srcp)
+{
+	return bitmap_weight(cpumask_bits(srcp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_shift_right - *dstp = *srcp >> n
+ * @dstp: the cpumask result
+ * @srcp: the input to shift
+ * @n: the number of bits to shift by
+ */
+static inline void cpumask_shift_right(struct cpumask *dstp,
+				       const struct cpumask *srcp, int n)
+{
+	bitmap_shift_right(cpumask_bits(dstp), cpumask_bits(srcp), n,
+					       nr_cpumask_bits);
+}
+
+/**
+ * cpumask_shift_left - *dstp = *srcp << n
+ * @dstp: the cpumask result
+ * @srcp: the input to shift
+ * @n: the number of bits to shift by
+ */
+static inline void cpumask_shift_left(struct cpumask *dstp,
+				      const struct cpumask *srcp, int n)
+{
+	bitmap_shift_left(cpumask_bits(dstp), cpumask_bits(srcp), n,
+					      nr_cpumask_bits);
+}
+
+/**
+ * cpumask_copy - *dstp = *srcp
+ * @dstp: the result
+ * @srcp: the input cpumask
+ */
+static inline void cpumask_copy(struct cpumask *dstp,
+				const struct cpumask *srcp)
+{
+	bitmap_copy(cpumask_bits(dstp), cpumask_bits(srcp), nr_cpumask_bits);
+}
+
+/**
+ * cpumask_any - pick a "random" cpu from *srcp
+ * @srcp: the input cpumask
+ *
+ * Returns >= nr_cpu_ids if no cpus set.
+ */
+#define cpumask_any(srcp) cpumask_first(srcp)
+
+/**
+ * cpumask_first_and - return the first cpu from *srcp1 & *srcp2
+ * @src1p: the first input
+ * @src2p: the second input
+ *
+ * Returns >= nr_cpu_ids if no cpus set in both.  See also cpumask_next_and().
+ */
+#define cpumask_first_and(src1p, src2p) cpumask_next_and(-1, (src1p), (src2p))
+
+/**
+ * cpumask_any_and - pick a "random" cpu from *mask1 & *mask2
+ * @mask1: the first input cpumask
+ * @mask2: the second input cpumask
+ *
+ * Returns >= nr_cpu_ids if no cpus set.
+ */
+#define cpumask_any_and(mask1, mask2) cpumask_first_and((mask1), (mask2))
+
+/**
+ * cpumask_of - the cpumask containing just a given cpu
+ * @cpu: the cpu (<= nr_cpu_ids)
+ */
+#define cpumask_of(cpu) (get_cpu_mask(cpu))
+
+/**
+ * to_cpumask - convert an NR_CPUS bitmap to a struct cpumask *
+ * @bitmap: the bitmap
+ *
+ * There are a few places where cpumask_var_t isn't appropriate and
+ * static cpumasks must be used (eg. very early boot), yet we don't
+ * expose the definition of 'struct cpumask'.
+ *
+ * This does the conversion, and can be used as a constant initializer.
+ */
+#define to_cpumask(bitmap)						\
+	((struct cpumask *)(1 ? (bitmap)				\
+			    : (void *)sizeof(__check_is_bitmap(bitmap))))
+
+static inline int __check_is_bitmap(const unsigned long *bitmap)
+{
+	return 1;
+}
+
+/**
+ * cpumask_size - size to allocate for a 'struct cpumask' in bytes
+ *
+ * This will eventually be a runtime variable, depending on nr_cpu_ids.
+ */
+static inline size_t cpumask_size(void)
+{
+	/* FIXME: Once all cpumask assignments are eliminated, this
+	 * can be nr_cpumask_bits */
+	return BITS_TO_LONGS(NR_CPUS) * sizeof(long);
+}
+
+/*
+ * cpumask_var_t: struct cpumask for stack usage.
+ *
+ * Oh, the wicked games we play!  In order to make kernel coding a
+ * little more difficult, we typedef cpumask_var_t to an array or a
+ * pointer: doing &mask on an array is a noop, so it still works.
+ *
+ * ie.
+ *	cpumask_var_t tmpmask;
+ *	if (!alloc_cpumask_var(&tmpmask, GFP_KERNEL))
+ *		return -ENOMEM;
+ *
+ *	  ... use 'tmpmask' like a normal struct cpumask * ...
+ *
+ *	free_cpumask_var(tmpmask);
+ */
+#ifdef CONFIG_CPUMASK_OFFSTACK
+typedef struct cpumask *cpumask_var_t;
+
+bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags);
+void alloc_bootmem_cpumask_var(cpumask_var_t *mask);
+void free_cpumask_var(cpumask_var_t mask);
+void free_bootmem_cpumask_var(cpumask_var_t mask);
+
+#else
+typedef struct cpumask cpumask_var_t[1];
+
+static inline bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags)
+{
+	return true;
+}
+
+static inline void alloc_bootmem_cpumask_var(cpumask_var_t *mask)
+{
+}
+
+static inline void free_cpumask_var(cpumask_var_t mask)
+{
+}
+
+static inline void free_bootmem_cpumask_var(cpumask_var_t mask)
+{
+}
+#endif /* CONFIG_CPUMASK_OFFSTACK */
+
+/* The pointer versions of the maps, these will become the primary versions. */
+#define cpu_possible_mask ((const struct cpumask *)&cpu_possible_map)
+#define cpu_online_mask ((const struct cpumask *)&cpu_online_map)
+#define cpu_present_mask ((const struct cpumask *)&cpu_present_map)
+#define cpu_active_mask ((const struct cpumask *)&cpu_active_map)
+
+/* It's common to want to use cpu_all_mask in struct member initializers,
+ * so it has to refer to an address rather than a pointer. */
+extern const DECLARE_BITMAP(cpu_all_bits, NR_CPUS);
+#define cpu_all_mask to_cpumask(cpu_all_bits)
+
+/* First bits of cpu_bit_bitmap are in fact unset. */
+#define cpu_none_mask to_cpumask(cpu_bit_bitmap[0])
+
+/* Wrappers for arch boot code to manipulate normally-constant masks */
+static inline void set_cpu_possible(unsigned int cpu, bool possible)
+{
+	if (possible)
+		cpumask_set_cpu(cpu, &cpu_possible_map);
+	else
+		cpumask_clear_cpu(cpu, &cpu_possible_map);
+}
+
+static inline void set_cpu_present(unsigned int cpu, bool present)
+{
+	if (present)
+		cpumask_set_cpu(cpu, &cpu_present_map);
+	else
+		cpumask_clear_cpu(cpu, &cpu_present_map);
+}
+
+static inline void set_cpu_online(unsigned int cpu, bool online)
+{
+	if (online)
+		cpumask_set_cpu(cpu, &cpu_online_map);
+	else
+		cpumask_clear_cpu(cpu, &cpu_online_map);
+}
+
+static inline void set_cpu_active(unsigned int cpu, bool active)
+{
+	if (active)
+		cpumask_set_cpu(cpu, &cpu_active_map);
+	else
+		cpumask_clear_cpu(cpu, &cpu_active_map);
+}
+
+static inline void init_cpu_present(const struct cpumask *src)
+{
+	cpumask_copy(&cpu_present_map, src);
+}
+
+static inline void init_cpu_possible(const struct cpumask *src)
+{
+	cpumask_copy(&cpu_possible_map, src);
+}
+
+static inline void init_cpu_online(const struct cpumask *src)
+{
+	cpumask_copy(&cpu_online_map, src);
+}
 #endif /* __LINUX_CPUMASK_H */
diff --git a/include/linux/smp.h b/include/linux/smp.h
index 2e4d58b..3f9a600 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -64,8 +64,17 @@ extern void smp_cpus_done(unsigned int max_cpus);
  * Call a function on all other processors
  */
 int smp_call_function(void(*func)(void *info), void *info, int wait);
+/* Deprecated: use smp_call_function_many() which uses a cpumask ptr. */
 int smp_call_function_mask(cpumask_t mask, void(*func)(void *info), void *info,
 				int wait);
+
+static inline void smp_call_function_many(const struct cpumask *mask,
+					  void (*func)(void *info), void *info,
+					  int wait)
+{
+	smp_call_function_mask(*mask, func, info, wait);
+}
+
 int smp_call_function_single(int cpuid, void (*func) (void *info), void *info,
 				int wait);
 void __smp_call_function_single(int cpuid, struct call_single_data *data);
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 89a5a12..b362911 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -240,4 +240,12 @@ void cancel_rearming_delayed_work(struct delayed_work *work)
 	cancel_delayed_work_sync(work);
 }
 
+#ifndef CONFIG_SMP
+static inline long work_on_cpu(unsigned int cpu, long (*fn)(void *), void *arg)
+{
+	return fn(arg);
+}
+#else
+long work_on_cpu(unsigned int cpu, long (*fn)(void *), void *arg);
+#endif /* CONFIG_SMP */
 #endif
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 86d4904..5a732c5 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -499,3 +499,6 @@ const unsigned long cpu_bit_bitmap[BITS_PER_LONG+1][BITS_TO_LONGS(NR_CPUS)] = {
 #endif
 };
 EXPORT_SYMBOL_GPL(cpu_bit_bitmap);
+
+const DECLARE_BITMAP(cpu_all_bits, NR_CPUS) = CPU_BITS_ALL;
+EXPORT_SYMBOL(cpu_all_bits);
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index f928f2a..d4dc69d 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -970,6 +970,51 @@ undo:
 	return ret;
 }
 
+#ifdef CONFIG_SMP
+struct work_for_cpu {
+	struct work_struct work;
+	long (*fn)(void *);
+	void *arg;
+	long ret;
+};
+
+static void do_work_for_cpu(struct work_struct *w)
+{
+	struct work_for_cpu *wfc = container_of(w, struct work_for_cpu, work);
+
+	wfc->ret = wfc->fn(wfc->arg);
+}
+
+/**
+ * work_on_cpu - run a function in user context on a particular cpu
+ * @cpu: the cpu to run on
+ * @fn: the function to run
+ * @arg: the function arg
+ *
+ * This will return -EINVAL in the cpu is not online, or the return value
+ * of @fn otherwise.
+ */
+long work_on_cpu(unsigned int cpu, long (*fn)(void *), void *arg)
+{
+	struct work_for_cpu wfc;
+
+	INIT_WORK(&wfc.work, do_work_for_cpu);
+	wfc.fn = fn;
+	wfc.arg = arg;
+	get_online_cpus();
+	if (unlikely(!cpu_online(cpu)))
+		wfc.ret = -EINVAL;
+	else {
+		schedule_work_on(cpu, &wfc.work);
+		flush_work(&wfc.work);
+	}
+	put_online_cpus();
+
+	return wfc.ret;
+}
+EXPORT_SYMBOL_GPL(work_on_cpu);
+#endif /* CONFIG_SMP */
+
 void __init init_workqueues(void)
 {
 	cpu_populated_map = cpu_online_map;
diff --git a/lib/cpumask.c b/lib/cpumask.c
index 5f97dc2..8d03f22 100644
--- a/lib/cpumask.c
+++ b/lib/cpumask.c
@@ -2,6 +2,7 @@
 #include <linux/bitops.h>
 #include <linux/cpumask.h>
 #include <linux/module.h>
+#include <linux/bootmem.h>
 
 int __first_cpu(const cpumask_t *srcp)
 {
@@ -35,3 +36,81 @@ int __any_online_cpu(const cpumask_t *mask)
 	return cpu;
 }
 EXPORT_SYMBOL(__any_online_cpu);
+
+/**
+ * cpumask_next_and - get the next cpu in *src1p & *src2p
+ * @n: the cpu prior to the place to search (ie. return will be > @n)
+ * @src1p: the first cpumask pointer
+ * @src2p: the second cpumask pointer
+ *
+ * Returns >= nr_cpu_ids if no further cpus set in both.
+ */
+int cpumask_next_and(int n, const struct cpumask *src1p,
+		     const struct cpumask *src2p)
+{
+	while ((n = cpumask_next(n, src1p)) < nr_cpu_ids)
+		if (cpumask_test_cpu(n, src2p))
+			break;
+	return n;
+}
+EXPORT_SYMBOL(cpumask_next_and);
+
+/**
+ * cpumask_any_but - return a "random" in a cpumask, but not this one.
+ * @mask: the cpumask to search
+ * @cpu: the cpu to ignore.
+ *
+ * Often used to find any cpu but smp_processor_id() in a mask.
+ * Returns >= nr_cpu_ids if no cpus set.
+ */
+int cpumask_any_but(const struct cpumask *mask, unsigned int cpu)
+{
+	unsigned int i;
+
+	cpumask_check(cpu);
+	for_each_cpu(i, mask)
+		if (i != cpu)
+			break;
+	return i;
+}
+
+/* These are not inline because of header tangles. */
+#ifdef CONFIG_CPUMASK_OFFSTACK
+bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags)
+{
+	if (likely(slab_is_available()))
+		*mask = kmalloc(cpumask_size(), flags);
+	else {
+#ifdef CONFIG_DEBUG_PER_CPU_MAPS
+		printk(KERN_ERR
+			"=> alloc_cpumask_var: kmalloc not available!\n");
+		dump_stack();
+#endif
+		*mask = NULL;
+	}
+#ifdef CONFIG_DEBUG_PER_CPU_MAPS
+	if (!*mask) {
+		printk(KERN_ERR "=> alloc_cpumask_var: failed!\n");
+		dump_stack();
+	}
+#endif
+	return *mask != NULL;
+}
+EXPORT_SYMBOL(alloc_cpumask_var);
+
+void __init alloc_bootmem_cpumask_var(cpumask_var_t *mask)
+{
+	*mask = alloc_bootmem(cpumask_size());
+}
+
+void free_cpumask_var(cpumask_var_t mask)
+{
+	kfree(mask);
+}
+EXPORT_SYMBOL(free_cpumask_var);
+
+void __init free_bootmem_cpumask_var(cpumask_var_t mask)
+{
+	free_bootmem((unsigned long)mask, cpumask_size());
+}
+#endif

Re: [PATCH] cpumask: introduce new API, without changing anything

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> > On Sat, 8 Nov 2008, Rusty Russell wrote:
> > > 
> > > Ok, I sent through the latest delta on top of this before, but see below.
> > 
> > Can somebody send a final patch-set to me? Right now I have multiple 
> > versions of patches, apparently on top of each other, and sometimes 
> > multiple patches per email. Very confusing, and I do _not_ want to 
> > apply the wrong thing by mistake.
> 
> I've got them collected and tested (and so has Rusty), see the tree 
> URI below. There's no pending problem left that i know of. I also 
> just did a fresh test-build and test-boot of this tree, for good 
> measure.

Thomas did a cross-build test of Linus's latest 
(v2.6.28-rc3-261-g8b805ef), and it seems OK (see the results below) - 
no new cross-build failures introduced.

	Ingo

--------------->
Run 142: 2008-11-09 21:38:04 .. 2008-11-09 22:30:35

Run 142: 17 of 19 operations OK
Run 142: 2 of 19 operations FAILED

http://www.tglx.de/autoqa-logs/000142-0008-0005.log
http://www.tglx.de/autoqa-logs/000142-0008-0015.log

Changed warnings:
http://www.tglx.de/autoqa-logs/d000141-000142-0008-0006.log
http://www.tglx.de/autoqa-logs/d000141-000142-0008-0023.log
http://www.tglx.de/autoqa-logs/d000141-000142-0008-0024.log

Full results at: http://www.tglx.de/autoqa/index
_______________________________________________
autoqa mailing list
autoqa@www.tglx.de
http://www.tglx.de/mailman/listinfo/autoqa

Re: [PATCH] cpumask: introduce new API, without changing anything

[Rusty Russell]

On Monday 10 November 2008 07:01:50 Linus Torvalds wrote:
> On Sat, 8 Nov 2008, Rusty Russell wrote:
> > Ok, I sent through the latest delta on top of this before, but see below.
>
> Can somebody send a final patch-set to me? Right now I have multiple
> versions of patches, apparently on top of each other, and sometimes
> multiple patches per email. Very confusing, and I do _not_ want to apply
> the wrong thing by mistake.

Sure, am waiting for a final run through linux-next.  There's no huge hurry 
and it helps find obscure arch compile/include issues.

Cheers,
Rusty.

Re: [PATCH] cpumask: introduce new API, without changing anything

[Mike Travis]

Ingo Molnar wrote:
...
> Mike, could you please double-check that the version that is in 
> tip/cpus4096 [622e0ed] is the final version you need, and that if you 
> base subsequent patches on it it works as expected?
...
I'm checking this out, so far it looks good.

> and once that patch hits upstream, we could restructure/rebase the 
> commits in cpus4096-v2 ontop of upstream and spread them out properly. 
> Does that sound optimal?

Yes, thanks.  I'm doing the x86 portion now.  Rusty is doing the other
arch and core changes.

linux-next: manual merge of the rr tree

[Stephen Rothwell]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
drivers/net/virtio_net.c between commit
8f15ea42b64941001a401cf855a0869e24f3a845 ("netdevice: safe convert to
netdev_priv() #part-3") from the net tree and commits
59c738ddde6c8661e70fb48ca5604cefed77da48 ("virtio_net: Recycle some more
rx buffer pages") and 6de41d64eb3558a4fca25f225f931e2ca7d419ab
("virtio_net: Improve the recv buffer allocation scheme") from the rr
tree.

I fixed it up (see below) and can carry the fix.  However, netdev_priv()
should be being used in the rr tree as it already exists in Linus' tree
and is used elsewhere in virtio_net.c.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc drivers/net/virtio_net.c
index ede0a80,79b59cc..0000000
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@@ -111,8 -120,10 +120,10 @@@ static void skb_xmit_done(struct virtqu
  static void receive_skb(struct net_device *dev, struct sk_buff *skb,
  			unsigned len)
  {
 -	struct virtnet_info *vi = dev->priv;
++	struct virtnet_info *vi = netdev_priv(dev);
  	struct virtio_net_hdr *hdr = skb_vnet_hdr(skb);
  	int err;
+ 	int i;
  
  	if (unlikely(len < sizeof(struct virtio_net_hdr) + ETH_HLEN)) {
  		pr_debug("%s: short packet %i\n", dev->name, len);
@@@ -326,10 -454,10 +454,8 @@@ static int xmit_skb(struct virtnet_inf
  
  	sg_init_table(sg, 2+MAX_SKB_FRAGS);
  
 -	pr_debug("%s: xmit %p " MAC_FMT "\n", vi->dev->name, skb,
 -		 dest[0], dest[1], dest[2],
 -		 dest[3], dest[4], dest[5]);
 +	pr_debug("%s: xmit %p %pM\n", vi->dev->name, skb, dest);
  
- 	/* Encode metadata header at front. */
- 	hdr = skb_vnet_hdr(skb);
  	if (skb->ip_summed == CHECKSUM_PARTIAL) {
  		hdr->flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;
  		hdr->csum_start = skb->csum_start - skb_headroom(skb);

Re: linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

Hi Rusty, Dave,

On Fri, 14 Nov 2008 15:13:17 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I fixed it up (see below) and can carry the fix.  However, netdev_priv()
> should be being used in the rr tree as it already exists in Linus' tree
> and is used elsewhere in virtio_net.c.

I guess the way forward (easiest for me :-)) is for Rusty's tree to use
netdev_priv() in that one last place in virtio_net.c and for Dave to
apply a patch to his tree that reverts just the virtio_net.c part of the
conflicting commit.

I think that will remove any conflict between the trees.  Thoughts?
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: manual merge of the rr tree

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 14 Nov 2008 15:20:54 +1100

> I guess the way forward (easiest for me :-)) is for Rusty's tree to use
> netdev_priv() in that one last place in virtio_net.c and for Dave to
> apply a patch to his tree that reverts just the virtio_net.c part of the
> conflicting commit.
> 
> I think that will remove any conflict between the trees.  Thoughts?

I'm open to just about anything that doesn't involve
rebasing my tree :)

Re: linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

Hi Dave,

On Thu, 13 Nov 2008 20:30:59 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> I'm open to just about anything that doesn't involve
> rebasing my tree :)

The only issue would be if you have patches to remove/rename the netdev
priv field - they would have to be delayed until after Rusty's tree was
merged, or someone could submit a trivial patch to Linus to do that last
netdev_priv() conversion in virtio_net.c and you could both rebase/merge
that.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: manual merge of the rr tree

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 14 Nov 2008 15:36:25 +1100

> Hi Dave,
> 
> On Thu, 13 Nov 2008 20:30:59 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> >
> > I'm open to just about anything that doesn't involve
> > rebasing my tree :)
> 
> The only issue would be if you have patches to remove/rename the netdev
> priv field - they would have to be delayed until after Rusty's tree was
> merged, or someone could submit a trivial patch to Linus to do that last
> netdev_priv() conversion in virtio_net.c and you could both rebase/merge
> that.

Another option is simply for Rusty to submit his virtio stuff
through my tree.  I'm more than happy to take care of that
as soon as Rusty can put the patches together.

Re: linux-next: manual merge of the rr tree

[Stephen Rothwell]

Hi Dave,

On Thu, 13 Nov 2008 20:41:21 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 14 Nov 2008 15:36:25 +1100
> 
> > The only issue would be if you have patches to remove/rename the netdev
> > priv field - they would have to be delayed until after Rusty's tree was
> > merged, or someone could submit a trivial patch to Linus to do that last
> > netdev_priv() conversion in virtio_net.c and you could both rebase/merge
> > that.
> 
> Another option is simply for Rusty to submit his virtio stuff
> through my tree.  I'm more than happy to take care of that
> as soon as Rusty can put the patches together.

I was about to send the below to Linus.  I will hold onto it for a couple
of days.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Linus <torvalds@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>, "David S. Miller"
 <davem@davemloft.net>, Rusty Russell <rusty@rustcorp.com.au>,
 netdev@vger.kernel.org
Subject: [PATCH] virtio: remove the last direct reference to the netdev priv field

This is to help with conflict resolution during the next merge window.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/net/virtio_net.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

Rusty, Dave, you will need to rebase/merge against Linus' tree after (if?)
this goes in.

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 0196a0d..fce1854 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -125,7 +125,8 @@ static void receive_skb(struct net_device *dev, struct sk_buff *skb,
 		unsigned int i;
 
 		for (i = 0; i < skb_shinfo(skb)->nr_frags; i++)
-			give_a_page(dev->priv, skb_shinfo(skb)->frags[i].page);
+			give_a_page(netdev_priv(dev),
+				skb_shinfo(skb)->frags[i].page);
 		skb->data_len = 0;
 		skb_shinfo(skb)->nr_frags = 0;
 	}
-- 
1.5.6.5

Re: linux-next: manual merge of the rr tree

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 14 Nov 2008 16:06:38 +1100

> On Thu, 13 Nov 2008 20:41:21 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Fri, 14 Nov 2008 15:36:25 +1100
> > 
> > > The only issue would be if you have patches to remove/rename the netdev
> > > priv field - they would have to be delayed until after Rusty's tree was
> > > merged, or someone could submit a trivial patch to Linus to do that last
> > > netdev_priv() conversion in virtio_net.c and you could both rebase/merge
> > > that.
> > 
> > Another option is simply for Rusty to submit his virtio stuff
> > through my tree.  I'm more than happy to take care of that
> > as soon as Rusty can put the patches together.
> 
> I was about to send the below to Linus.  I will hold onto it for a couple
> of days.

Ok.  We'll try to sort it out.

Rusty, are your changes 2.6.28 bound or -next?

Re: linux-next: manual merge of the rr tree

[Rusty Russell]

On Friday 14 November 2008 17:12:55 David Miller wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 14 Nov 2008 16:06:38 +1100
>
> > On Thu, 13 Nov 2008 20:41:21 -0800 (PST) David Miller 
<davem@davemloft.net> wrote:
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Date: Fri, 14 Nov 2008 15:36:25 +1100
> > >
> > > > The only issue would be if you have patches to remove/rename the
> > > > netdev priv field - they would have to be delayed until after Rusty's
> > > > tree was merged, or someone could submit a trivial patch to Linus to
> > > > do that last netdev_priv() conversion in virtio_net.c and you could
> > > > both rebase/merge that.
> > >
> > > Another option is simply for Rusty to submit his virtio stuff
> > > through my tree.  I'm more than happy to take care of that
> > > as soon as Rusty can put the patches together.
> >
> > I was about to send the below to Linus.  I will hold onto it for a couple
> > of days.
>
> Ok.  We'll try to sort it out.
>
> Rusty, are your changes 2.6.28 bound or -next?

They missed 2.6.28, they're 2.6.29 material.  I've fixed them with s/dev-
>priv/netdev_priv(dev)/, and will send them to netdev now.

Thanks,
Rusty.

Re: linux-next: manual merge of the rr tree

[David Miller]

From: Rusty Russell <rusty@rustcorp.com.au>
Date: Sun, 16 Nov 2008 09:02:52 +1030

> They missed 2.6.28, they're 2.6.29 material.  I've fixed them with s/dev-
> >priv/netdev_priv(dev)/, and will send them to netdev now.

I haven't seen them posted yet, so could you please clarify you're
definition of "now"? :-)

linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
arch/s390/include/asm/smp.h arch/s390/kernel/smp.c between commit
32d13157b60c5499c858adaecb6a01873ff9a81a ("[S390] convert s390 to generic
IPI infrastructure") from the s390 tree and commit
0a74a1ee6aaf74b687d649be3196c17f148127ea
("cpumask:smp_call_function_many") from the rr tree.

I think (I may be wrong) that the s390 tree change has removed the need
for the rr tree change to touch the s390 files.  I fixed it up
accordingly and can carry the fix.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: manual merge of the rr tree

[Rusty Russell]

On Thursday 20 November 2008 13:54:04 Stephen Rothwell wrote:
> Hi Rusty,
>
> Today's linux-next merge of the rr tree got a conflict in
> arch/s390/include/asm/smp.h arch/s390/kernel/smp.c between commit
> 32d13157b60c5499c858adaecb6a01873ff9a81a ("[S390] convert s390 to generic
> IPI infrastructure") from the s390 tree and commit
> 0a74a1ee6aaf74b687d649be3196c17f148127ea
> ("cpumask:smp_call_function_many") from the rr tree.
>
> I think (I may be wrong) that the s390 tree change has removed the need
> for the rr tree change to touch the s390 files.  I fixed it up
> accordingly and can carry the fix.

That's great, I didn't know they were doing that.

Thanks, I'll drop that part of the patch.
Rusty.

linux-next: manual merge of the rr tree

[Stephen Rothwell]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
kernel/irq/manage.c between commit
612e3684c1b7752d2890510e4f90115fd1eb2afb ("genirq: fix the affinity
setting in setup_irq") from the genirq tree and commit
5b03e170d524383a34a89fd73ec9d1bda0922d63
("cpumask:irq-functions-take-cpumask_t-ptr") from the rr tree.

I fixed it up (see below) and can carry it.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc kernel/irq/manage.c
index 4358612,7dc7563..0000000
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@@ -123,9 -119,10 +119,10 @@@ int do_irq_select_affinity(unsigned in
  	 * Preserve an userspace affinity setup, but make sure that
  	 * one of the targets is online.
  	 */
 -	if (desc->status & IRQ_AFFINITY_SET) {
 +	if (desc->status & (IRQ_AFFINITY_SET | IRQ_NO_BALANCING)) {
- 		if (cpus_intersects(desc->affinity, cpu_online_map))
- 			mask = desc->affinity;
+ 		if (cpumask_any_and(&desc->affinity, cpu_online_mask)
+ 		    < nr_cpu_ids)
+ 			goto set_affinity;
  		else
  			desc->status &= ~IRQ_AFFINITY_SET;
  	}

linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

Hi Rusty,

Today's linux-next merge of the rr tree got conflicts in the same files
as the rr_cpumask tree plus a few more.  Coming on top of the rr_cpumask
conflicts, it was a bit much for today, so I have dropped the rr tree.
Please see if you can sort it out a bit for tomorrow.  Or at least give
me a hint as to how to fix the conflicts.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: manual merge of the rr tree

[Stephen Rothwell]

Hi Rusty,

Today's linux-next merge of the rr tree got conflicts in kernel/sched.c
between commits abcd083a1a658d2bc1f7fced02632bfe03918002 ("sched: convert
sched.c from for_each_cpu_mask to for_each_cpu"),
3404c8d97c2d3eb87b1bf4aadad957bfb5235b14 ("sched: get rid of boutique
sched.c allocations, use cpumask_var_t"),
758b2cdc6f6a22c702bd8f2344382fb1270b2161 ("sched: wrap sched_group and
sched_domain cpumask accesses") and
96f874e26428ab5d2db681c100210c254775e154 ("sched: convert remaining
old-style cpumask operators") from the cpus4096 tree and commit
13d3341b638c61d2c69371b021c503c9a9c824bd
("cpumask:use-cpu_coregroup_mask") from the rr tree.

I fixed it up as best I could (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc kernel/sched.c
index dc97b8a,4292923..0000000
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@@ -7138,13 -7119,13 +7138,12 @@@ cpu_to_phys_group(int cpu, const struc
  {
  	int group;
  #ifdef CONFIG_SCHED_MC
- 	/* FIXME: Use cpu_coregroup_mask. */
- 	*mask = cpu_coregroup_map(cpu);
+ 	*mask = *cpu_coregroup_mask(cpu);
  	cpus_and(*mask, *mask, *cpu_map);
 -	group = first_cpu(*mask);
 +	group = cpumask_first(mask);
  #elif defined(CONFIG_SCHED_SMT)
 -	*mask = per_cpu(cpu_sibling_map, cpu);
 -	cpus_and(*mask, *mask, *cpu_map);
 -	group = first_cpu(*mask);
 +	cpumask_and(mask, &per_cpu(cpu_sibling_map, cpu), cpu_map);
 +	group = cpumask_first(mask);
  #else
  	group = cpu;
  #endif
@@@ -7476,12 -7482,11 +7475,12 @@@ static int __build_sched_domains(const 
  
  #ifdef CONFIG_SCHED_MC
  		p = sd;
 -		sd = &per_cpu(core_domains, i);
 +		sd = &per_cpu(core_domains, i).sd;
  		SD_INIT(sd, MC);
  		set_domain_attribute(sd, attr);
- 		*sched_domain_span(sd) = cpu_coregroup_map(i);
 -		sd->span = *cpu_coregroup_mask(i);
 -		cpus_and(sd->span, sd->span, *cpu_map);
++		*sched_domain_span(sd) = *cpu_coregroup_mask(i);
 +		cpumask_and(sched_domain_span(sd),
 +			    sched_domain_span(sd), cpu_map);
  		sd->parent = p;
  		p->child = sd;
  		cpu_to_core_group(i, cpu_map, &sd->groups, tmpmask);
@@@ -7516,11 -7524,13 +7515,10 @@@
  
  #ifdef CONFIG_SCHED_MC
  	/* Set up multi-core groups */
 -	for_each_cpu_mask_nr(i, *cpu_map) {
 -		SCHED_CPUMASK_VAR(this_core_map, allmasks);
 -		SCHED_CPUMASK_VAR(send_covered, allmasks);
 -
 +	for_each_cpu(i, cpu_map) {
- 		/* FIXME: Use cpu_coregroup_mask */
- 		*this_core_map = cpu_coregroup_map(i);
+ 		*this_core_map = *cpu_coregroup_mask(i);
  		cpus_and(*this_core_map, *this_core_map, *cpu_map);
 -		if (i != first_cpu(*this_core_map))
 +		if (i != cpumask_first(this_core_map))
  			continue;
  
  		init_sched_build_groups(this_core_map, cpu_map,

linux-next: manual merge of the rr tree

[Stephen Rothwell]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
drivers/virtio/virtio_pci.c between commit
b5146336e3bc3786712919e94106063036dae86b ("virtio: do not statically
allocate root device") from the driver-core tree and commits
f53dba3a1ea82dfb37f094a942ae74032413809f ("virtio: struct device -
replace bus_id with dev_name(), dev_set_name()") and
ab4e479d47ceac2fa5bebd5b99d27f01fe0e0c8b ("virtio: add PCI device release
() function") from the rr tree.

I fixed it up (see below) and can carry the fix as necessary.  Mark, does
this driver-core patch obsolete the second rr tree patch above?
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc drivers/virtio/virtio_pci.c
index f772cc4,265fdf2..0000000
--- a/drivers/virtio/virtio_pci.c
+++ b/drivers/virtio/virtio_pci.c
@@@ -324,7 -343,8 +340,8 @@@ static int __devinit virtio_pci_probe(s
  	if (vp_dev == NULL)
  		return -ENOMEM;
  
 -	vp_dev->vdev.dev.parent = &virtio_pci_root;
 +	vp_dev->vdev.dev.parent = virtio_pci_root;
+ 	vp_dev->vdev.dev.release = virtio_pci_release_dev;
  	vp_dev->vdev.config = &virtio_pci_config_ops;
  	vp_dev->pci_dev = pci_dev;
  	INIT_LIST_HEAD(&vp_dev->virtqueues);

Re: linux-next: manual merge of the rr tree

[Rusty Russell]

On Monday 22 December 2008 17:02:13 Stephen Rothwell wrote:
> Hi Rusty,
> 
> Today's linux-next merge of the rr tree got a conflict in
> drivers/virtio/virtio_pci.c between commit
> b5146336e3bc3786712919e94106063036dae86b ("virtio: do not statically
> allocate root device") from the driver-core tree and commits
> f53dba3a1ea82dfb37f094a942ae74032413809f ("virtio: struct device -
> replace bus_id with dev_name(), dev_set_name()") and
> ab4e479d47ceac2fa5bebd5b99d27f01fe0e0c8b ("virtio: add PCI device release
> () function") from the rr tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.  Mark, does
> this driver-core patch obsolete the second rr tree patch above?

This is not unexpected.  Mark sent me those two, the others went to
Greg.  I'm happy to ack them and send them on to Greg.

Thanks,
Rusty.

Re: linux-next: manual merge of the rr tree

[Mark McLoughlin]

Hi Stephen/Rusty,

On Mon, 2008-12-22 at 18:28 +1030, Rusty Russell wrote:
> On Monday 22 December 2008 17:02:13 Stephen Rothwell wrote:
> > Hi Rusty,
> > 
> > Today's linux-next merge of the rr tree got a conflict in
> > drivers/virtio/virtio_pci.c between commit
> > b5146336e3bc3786712919e94106063036dae86b ("virtio: do not statically
> > allocate root device") from the driver-core tree and commits
> > f53dba3a1ea82dfb37f094a942ae74032413809f ("virtio: struct device -
> > replace bus_id with dev_name(), dev_set_name()") and
> > ab4e479d47ceac2fa5bebd5b99d27f01fe0e0c8b ("virtio: add PCI device release
> > () function") from the rr tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary.  Mark, does
> > this driver-core patch obsolete the second rr tree patch above?

The conflict resolution is correct.

> This is not unexpected.  Mark sent me those two, the others went to
> Greg.  I'm happy to ack them and send them on to Greg.

You could do that, or let Stephen carry the fixup or pull these bits
from Greg's tree into your before NEXT_PATCHES_START:

  http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/driver-core/driver-core-add-root_device_register.patch
  http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/driver-core/virtio-do-not-statically-allocate-root-device.patch

Thanks,
Mark.

linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
kernel/rcuclassic.c between commit
6a7b3dc3440f7b5a9b67594af01ed562cdeb41e4 ("sched: convert nohz_cpu_mask
to cpumask_var_t") from the cpus4096 tree and commit
fe9482e26320b110e102afa01f84c3302d0b1593 ("cpumask: convert RCU
implementations") from the rr tree.

I fixed it up (used the rr tree version) and can carry the fix as
necessary.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
kernel/workqueue.c between commit
6cc88bc45ce8043171089c9592da223dfab91823 ("CRED: Rename is_single_threaded
() to is_wq_single_threaded()") from the Linus' tree and commit
74356d280154b04fb6d9dae10833a6ab6203735a
("cpumask:convert-kernel_workqueue.c") from the rr tree.

I fixed it up (used the rr tree version) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

Hi Rusty,

On Mon, 29 Dec 2008 18:47:21 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the rr tree got a conflict in
> kernel/rcuclassic.c between commit
> 6a7b3dc3440f7b5a9b67594af01ed562cdeb41e4 ("sched: convert nohz_cpu_mask
> to cpumask_var_t") from the cpus4096 tree and commit
> fe9482e26320b110e102afa01f84c3302d0b1593 ("cpumask: convert RCU
> implementations") from the rr tree.
> 
> I fixed it up (used the rr tree version) and can carry the fix as
> necessary.

Which I assume was wrong since I got this warning:

kernel/rcuclassic.c: In function 'rcu_start_batch':
kernel/rcuclassic.c:398: warning: passing argument 3 of 'cpumask_andnot' from incompatible pointer type

So I added back the '&' on the third argument.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]

Hi Greg,

On Mon, 22 Dec 2008 17:32:13 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the rr tree got a conflict in
> drivers/virtio/virtio_pci.c between commit
> b5146336e3bc3786712919e94106063036dae86b ("virtio: do not statically
> allocate root device") from the driver-core tree and commits
> f53dba3a1ea82dfb37f094a942ae74032413809f ("virtio: struct device -
> replace bus_id with dev_name(), dev_set_name()") and
> ab4e479d47ceac2fa5bebd5b99d27f01fe0e0c8b ("virtio: add PCI device release
> () function") from the rr tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.  Mark, does
> this driver-core patch obsolete the second rr tree patch above?
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
> 
> diff --cc drivers/virtio/virtio_pci.c
> index f772cc4,265fdf2..0000000
> --- a/drivers/virtio/virtio_pci.c
> +++ b/drivers/virtio/virtio_pci.c
> @@@ -324,7 -343,8 +340,8 @@@ static int __devinit virtio_pci_probe(s
>   	if (vp_dev == NULL)
>   		return -ENOMEM;
>   
>  -	vp_dev->vdev.dev.parent = &virtio_pci_root;
>  +	vp_dev->vdev.dev.parent = virtio_pci_root;
> + 	vp_dev->vdev.dev.release = virtio_pci_release_dev;
>   	vp_dev->vdev.config = &virtio_pci_config_ops;
>   	vp_dev->pci_dev = pci_dev;
>   	INIT_LIST_HEAD(&vp_dev->virtqueues);

This conflict is now between Linus' tree and the driver-core tree.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in kernel/module.c
between commit d3794979a8a80c222ce9d016a6dfc4bed36965d0 ("Zero based
percpu: infrastructure to rebase the per cpu area to zero") from the
tip-core tree and the cpualloc patches from the rr tree.

It requires better understanding than I have time for today, so I have
dropped the rr tree for today.

Similarly with init/main.c, include/linux/percpu.h,
include/asm-generic/percpu.h and arch/x86/include/asm/percpu.h (though
against different commits/trees, of course).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: manual merge of the rr tree

[Greg KH]

On Mon, Jan 05, 2009 at 10:30:36AM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> On Mon, 22 Dec 2008 17:32:13 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the rr tree got a conflict in
> > drivers/virtio/virtio_pci.c between commit
> > b5146336e3bc3786712919e94106063036dae86b ("virtio: do not statically
> > allocate root device") from the driver-core tree and commits
> > f53dba3a1ea82dfb37f094a942ae74032413809f ("virtio: struct device -
> > replace bus_id with dev_name(), dev_set_name()") and
> > ab4e479d47ceac2fa5bebd5b99d27f01fe0e0c8b ("virtio: add PCI device release
> > () function") from the rr tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary.  Mark, does
> > this driver-core patch obsolete the second rr tree patch above?
> > -- 
> > Cheers,
> > Stephen Rothwell                    sfr@canb.auug.org.au
> > http://www.canb.auug.org.au/~sfr/
> > 
> > diff --cc drivers/virtio/virtio_pci.c
> > index f772cc4,265fdf2..0000000
> > --- a/drivers/virtio/virtio_pci.c
> > +++ b/drivers/virtio/virtio_pci.c
> > @@@ -324,7 -343,8 +340,8 @@@ static int __devinit virtio_pci_probe(s
> >   	if (vp_dev == NULL)
> >   		return -ENOMEM;
> >   
> >  -	vp_dev->vdev.dev.parent = &virtio_pci_root;
> >  +	vp_dev->vdev.dev.parent = virtio_pci_root;
> > + 	vp_dev->vdev.dev.release = virtio_pci_release_dev;
> >   	vp_dev->vdev.config = &virtio_pci_config_ops;
> >   	vp_dev->pci_dev = pci_dev;
> >   	INIT_LIST_HEAD(&vp_dev->virtqueues);
> 
> This conflict is now between Linus' tree and the driver-core tree.

Thanks for letting me know, I'll fix it up tomorrow when I get back to
the patch queues :)

greg k-h

Re: linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 299 bytes --]

Hi Greg,

On Sun, 4 Jan 2009 20:36:23 -0800 Greg KH <greg@kroah.com> wrote:
>
> Thanks for letting me know, I'll fix it up tomorrow when I get back to
> the patch queues :)

Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: manual merge of the rr tree

[Rusty Russell]

On Monday 05 January 2009 14:02:39 Stephen Rothwell wrote:
> Hi Rusty,
> 
> Today's linux-next merge of the rr tree got a conflict in kernel/module.c
> between commit d3794979a8a80c222ce9d016a6dfc4bed36965d0 ("Zero based
> percpu: infrastructure to rebase the per cpu area to zero") from the
> tip-core tree and the cpualloc patches from the rr tree.

That's a sweet patch, but there are a few issues with it.  Main one is
that noone sets CONFIG_HAVE_ZERO_BASED_PER_CPU yet.  Is there more sitting
outside the tree, Mike?

1) Author is wrong.  This is Christoph's, not Mike's.
2) module.c now includes asm/sections.h twice.
3) We do still need RELOC_HIDE: it's for the compiler, not us.  It
   can otherwise make assumptions about pointers remaining within objects.
4) Defining SHIFT_PERCPU_PTR for UP, and DEFINE_PER_CPU_FIRST are currently
   unnecessary.  I assume for future patches, but I want to see them!

Thanks,
Rusty.

Re: linux-next: manual merge of the rr tree

[Rusty Russell]

[-- Attachment #1: Type: text/plain, Size: 4487 bytes --]

On Monday 05 January 2009 14:02:39 Stephen Rothwell wrote:
> Similarly with init/main.c, include/linux/percpu.h,
> include/asm-generic/percpu.h and arch/x86/include/asm/percpu.h (though
> against different commits/trees, of course).

OK, here's the merge as I did it.  I've also attached a tarball of the files
post-merge.

Cheers,
Rusty.

diff --cc arch/x86/include/asm/percpu.h
index 5c0ef60,313b3d6..0000000
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
diff --cc include/asm-generic/percpu.h
index 627b446,1c02250..0000000
--- a/include/asm-generic/percpu.h
+++ b/include/asm-generic/percpu.h
@@@ -117,11 -75,10 +117,15 @@@ extern void setup_per_cpu_areas(void)
  #define per_cpu(var, cpu)			(*((void)(cpu), &per_cpu_var(var)))
  #define __get_cpu_var(var)			per_cpu_var(var)
  #define __raw_get_cpu_var(var)			per_cpu_var(var)
 +#define read_percpu_var(var)			(0, per_cpu_var(var))
 +#define per_cpu_ptr(ptr, cpu)			(ptr)
 +#define __get_cpu_ptr(ptr)			(ptr)
 +#define __raw_get_cpu_ptr(ptr)			(ptr)
 +#define read_percpu_ptr(ptr)			(0, *(ptr))
+ #ifndef SHIFT_PERCPU_PTR
+ # define SHIFT_PERCPU_PTR(__p, __offset)		(__p)
+ #endif
+ #define per_cpu_offset(x)			0L
  
  #endif	/* SMP */
  
diff --cc include/linux/percpu.h
index dad0070,e1f8708..0000000
--- a/include/linux/percpu.h
+++ b/include/linux/percpu.h
@@@ -26,25 -26,46 +26,40 @@@
  
  #define DEFINE_PER_CPU_PAGE_ALIGNED(type, name)			\
  	__attribute__((__section__(".data.percpu.page_aligned")))	\
 -	PER_CPU_ATTRIBUTES __typeof__(type) per_cpu__##name
 +	PER_CPU_ATTRIBUTES __typeof__(type) __percpu name
+ 
+ #ifdef CONFIG_HAVE_ZERO_BASED_PER_CPU
+ #define DEFINE_PER_CPU_FIRST(type, name)				\
+ 	__attribute__((__section__(".data.percpu.first")))		\
 -	PER_CPU_ATTRIBUTES __typeof__(type) per_cpu__##name
++	PER_CPU_ATTRIBUTES __typeof__(type) __percpu name
  #else
+ #define DEFINE_PER_CPU_FIRST(type, name)				\
+ 	DEFINE_PER_CPU(type, name)
+ #endif
+ 
+ #else /* !CONFIG_SMP */
+ 
  #define DEFINE_PER_CPU(type, name)					\
 -	PER_CPU_ATTRIBUTES __typeof__(type) per_cpu__##name
 +	PER_CPU_ATTRIBUTES __typeof__(type) __percpu name
  
  #define DEFINE_PER_CPU_SHARED_ALIGNED(type, name)		      \
  	DEFINE_PER_CPU(type, name)
  
  #define DEFINE_PER_CPU_PAGE_ALIGNED(type, name)		      \
  	DEFINE_PER_CPU(type, name)
- #endif
+ 
+ #define DEFINE_PER_CPU_FIRST(type, name)				\
+ 	DEFINE_PER_CPU(type, name)
+ 
+ #endif /* !CONFIG_SMP */
  
 -#define EXPORT_PER_CPU_SYMBOL(var) EXPORT_SYMBOL(per_cpu__##var)
 -#define EXPORT_PER_CPU_SYMBOL_GPL(var) EXPORT_SYMBOL_GPL(per_cpu__##var)
 +#define EXPORT_PER_CPU_SYMBOL(var) EXPORT_SYMBOL(var)
 +#define EXPORT_PER_CPU_SYMBOL_GPL(var) EXPORT_SYMBOL_GPL(var)
  
 -/* Enough to cover all DEFINE_PER_CPUs in kernel, including modules. */
  #ifndef PERCPU_ENOUGH_ROOM
 -#ifdef CONFIG_MODULES
 -#define PERCPU_MODULE_RESERVE	8192
 -#else
 -#define PERCPU_MODULE_RESERVE	0
 -#endif
 +extern unsigned int percpu_reserve;
  
 -#define PERCPU_ENOUGH_ROOM						\
 -	(__per_cpu_end - __per_cpu_start + PERCPU_MODULE_RESERVE)
 +#define PERCPU_ENOUGH_ROOM (__per_cpu_end - __per_cpu_start + percpu_reserve)
  #endif	/* PERCPU_ENOUGH_ROOM */
  
  /*
diff --cc init/main.c
index 8a2d82c,d1c5b8b..0000000
--- a/init/main.c
+++ b/init/main.c
diff --cc kernel/module.c
index 99d1756,9712c52..0000000
--- a/kernel/module.c
+++ b/kernel/module.c
diff --git a/mm/allocpercpu.c b/mm/allocpercpu.c
index fa7f356..e77284f 100644
--- a/mm/allocpercpu.c
+++ b/mm/allocpercpu.c
@@ -61,7 +61,7 @@ void *__alloc_percpu(unsigned long size, unsigned long align)
 	if (WARN_ON(align > PAGE_SIZE))
 		align = PAGE_SIZE;
 
-	ptr = __per_cpu_start;
+	ptr = __per_cpu_load;
 	for (i = 0; i < pcpu_num_used; ptr += block_size(pcpu_size[i]), i++) {
 		/* Extra for alignment requirement. */
 		extra = ALIGN((unsigned long)ptr, align) - (unsigned long)ptr;
@@ -107,7 +107,7 @@ EXPORT_SYMBOL_GPL(__alloc_percpu);
 void free_percpu(void *freeme)
 {
 	unsigned int i;
-	void *ptr = __per_cpu_start + block_size(pcpu_size[0]);
+	void *ptr = __per_cpu_load + block_size(pcpu_size[0]);
 
 	if (!freeme)
 		return;
@@ -147,7 +147,7 @@ void __init percpu_alloc_init(void)
 	pcpu_size = kmalloc(sizeof(pcpu_size[0]) * pcpu_num_allocated,
 			    GFP_KERNEL);
 	/* Static in-kernel percpu data (used). */
-	pcpu_size[0] = -(__per_cpu_end-__per_cpu_start);
+	pcpu_size[0] = -__per_cpu_size;
 	/* Free room. */
 	pcpu_size[1] = PERCPU_ENOUGH_ROOM + pcpu_size[0];
 	BUG_ON(pcpu_size[1] < 0);

[-- Attachment #2: files.tar.bz2 --]
[-- Type: application/x-bzip-compressed-tar, Size: 27310 bytes --]

Re: linux-next: manual merge of the rr tree

[Ingo Molnar]

* Rusty Russell <rusty@rustcorp.com.au> wrote:

> On Monday 05 January 2009 14:02:39 Stephen Rothwell wrote:
> > Hi Rusty,
> > 
> > Today's linux-next merge of the rr tree got a conflict in kernel/module.c
> > between commit d3794979a8a80c222ce9d016a6dfc4bed36965d0 ("Zero based
> > percpu: infrastructure to rebase the per cpu area to zero") from the
> > tip-core tree and the cpualloc patches from the rr tree.
> 
> That's a sweet patch, but there are a few issues with it.  Main one is
> that noone sets CONFIG_HAVE_ZERO_BASED_PER_CPU yet.  Is there more sitting
> outside the tree, Mike?
> 
> 1) Author is wrong.  This is Christoph's, not Mike's.

yes - as can be seen from the signoff lineup. Mike's scripts ate a From: 
line i guess. (this was months ago)

> 2) module.c now includes asm/sections.h twice.
> 3) We do still need RELOC_HIDE: it's for the compiler, not us.  It
>    can otherwise make assumptions about pointers remaining within objects.
> 4) Defining SHIFT_PERCPU_PTR for UP, and DEFINE_PER_CPU_FIRST are currently
>    unnecessary.  I assume for future patches, but I want to see them!

i'm inclined to drop all of tip/core/percpu where these are located:

 41f395c: Merge commit 'v2.6.28-rc8' into core/percpu
 d74f61b: Merge branch 'linus' into core/percpu
 f8d90d9: percpu: zero based percpu build error on s390
 cfcfdff: Merge branch 'linus' into core/percpu
 d379497: Zero based percpu: infrastructure to rebase the per cpu area to zero
 b3a0cb4: x86: extend percpu ops to 64 bit

i didnt send them to Linus in this merge window because it was visibly 
orphaned.

That would allow Mike, Christoph and you to work this out cleanly from 
scratch. It would also solve your merge conflict.

Does that sound like a good solution?

	Ingo

Re: linux-next: manual merge of the rr tree

[Christoph Lameter]

On Mon, 5 Jan 2009, Rusty Russell wrote:

> 3) We do still need RELOC_HIDE: it's for the compiler, not us.  It
>    can otherwise make assumptions about pointers remaining within objects.

Never heard about that one. If the compiler would make the assumption that
pointers stay within a struct then the processor could hold data from
another per cpu section in registers while writing to the per cpu variable
of that per cpu section right?

But doesnt GCC invalidate all object pointers to a certain type of struct
if one field is modified?

And how will this work in cases where the pointer value is converted to
unsigned long?

Re: linux-next: manual merge of the rr tree

[Mike Travis]

Rusty Russell wrote:
> On Monday 05 January 2009 14:02:39 Stephen Rothwell wrote:
>> Hi Rusty,
>>
>> Today's linux-next merge of the rr tree got a conflict in kernel/module.c
>> between commit d3794979a8a80c222ce9d016a6dfc4bed36965d0 ("Zero based
>> percpu: infrastructure to rebase the per cpu area to zero") from the
>> tip-core tree and the cpualloc patches from the rr tree.
> 
> That's a sweet patch, but there are a few issues with it.  Main one is
> that noone sets CONFIG_HAVE_ZERO_BASED_PER_CPU yet.  Is there more sitting
> outside the tree, Mike?

I have not had a chance to look at the new patch.  The one that I was working
on had an issue with bootup on x86_64 with certain gcc versions and got dropped
at the last moment.  Missing merge windows for the NR_CPUS=4096 changes was far
more critical to SGI.

> 
> 1) Author is wrong.  This is Christoph's, not Mike's.

Yes, most of the core code was Christoph's.  This was before I learned about
the 'From:' line in the patch.  I added some of the code to make it actually
work. ;-)

> 2) module.c now includes asm/sections.h twice.
> 3) We do still need RELOC_HIDE: it's for the compiler, not us.  It
>    can otherwise make assumptions about pointers remaining within objects.
> 4) Defining SHIFT_PERCPU_PTR for UP, and DEFINE_PER_CPU_FIRST are currently
>    unnecessary.  I assume for future patches, but I want to see them!
> 
> Thanks,
> Rusty.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: manual merge of the rr tree

[Rusty Russell]

On Tuesday 06 January 2009 01:59:28 Christoph Lameter wrote:
> On Mon, 5 Jan 2009, Rusty Russell wrote:
> 
> > 3) We do still need RELOC_HIDE: it's for the compiler, not us.  It
> >    can otherwise make assumptions about pointers remaining within objects.
> 
> Never heard about that one. If the compiler would make the assumption that
> pointers stay within a struct then the processor could hold data from
> another per cpu section in registers while writing to the per cpu variable
> of that per cpu section right?
> 
> But doesnt GCC invalidate all object pointers to a certain type of struct
> if one field is modified?

It was a Richard Henderson thing.  It was over six years ago, but I found
one decent reference to it:

	http://lwn.net/2002/0214/a/per-cpu.php3

Hope that answers your question?
Rusty.

linux-next: manual merge of the rr tree

[Stephen Rothwell]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in init/main.c
between commit b9ce08c01020eb28bfbfa6faf1c740281c5f418e ("kmemtrace: Core
implementation") from the ftrace tree and commit
4289941b45ac95092f80c23d08ee88ccbd7635a3
("cpualloc:expose-module-percpu-allocator") from the rr tree.

Juts trivial overlapping additions.  I fixed it up (see below) and can
carry the fix as necessary.  I wasn't actually sure if the order
matters ...
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc init/main.c
index 240e1ef,8a2d82c..0000000
--- a/init/main.c
+++ b/init/main.c
@@@ -650,7 -650,7 +658,8 @@@ asmlinkage void __init start_kernel(voi
  	enable_debug_pagealloc();
  	cpu_hotplug_init();
  	kmem_cache_init();
+ 	percpu_alloc_init();
 +	kmemtrace_init();
  	debug_objects_mem_init();
  	idr_init_cache();
  	setup_per_cpu_pageset();

Re: linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

Hi Rusty,

On Mon, 5 Jan 2009 19:11:52 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote:
>
> On Monday 05 January 2009 14:02:39 Stephen Rothwell wrote:
> > Similarly with init/main.c, include/linux/percpu.h,
> > include/asm-generic/percpu.h and arch/x86/include/asm/percpu.h (though
> > against different commits/trees, of course).
> 
> OK, here's the merge as I did it.  I've also attached a tarball of the files
> post-merge.

Sorry to put you to all this work, but Ingo has rendered it unneeded by
dropping the other patches.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: manual merge of the rr tree

[Rusty Russell]

On Monday 05 January 2009 23:17:45 Ingo Molnar wrote:
> That would allow Mike, Christoph and you to work this out cleanly from 
> scratch. It would also solve your merge conflict.
> 
> Does that sound like a good solution?

Sure, but it won't make this window.  I guess since those patches don't
do anything but lay groundwork it's not critical, but annoying they've
lain fallow so long.

I'm happy to put them with the cpualloc patches, since they're related
and going to conflict, but I still want to see if Mike has the rest of them?

Thanks,
Rusty.

Re: linux-next: manual merge of the rr tree

[Ingo Molnar]

* Rusty Russell <rusty@rustcorp.com.au> wrote:

> On Monday 05 January 2009 23:17:45 Ingo Molnar wrote:
> > That would allow Mike, Christoph and you to work this out cleanly from 
> > scratch. It would also solve your merge conflict.
> > 
> > Does that sound like a good solution?
> 
> Sure, but it won't make this window.  I guess since those patches don't 
> do anything but lay groundwork it's not critical, but annoying they've 
> lain fallow so long.
> 
> I'm happy to put them with the cpualloc patches, since they're related 
> and going to conflict, but I still want to see if Mike has the rest of 
> them?

ok, i've zapped them from tip/core/percpu and will let you and Mike handle 
them.

	Ingo

Re: linux-next: manual merge of the rr tree

[Mike Travis]

Rusty Russell wrote:
> On Monday 05 January 2009 23:17:45 Ingo Molnar wrote:
>> That would allow Mike, Christoph and you to work this out cleanly from 
>> scratch. It would also solve your merge conflict.
>>
>> Does that sound like a good solution?
> 
> Sure, but it won't make this window.  I guess since those patches don't
> do anything but lay groundwork it's not critical, but annoying they've
> lain fallow so long.
> 
> I'm happy to put them with the cpualloc patches, since they're related
> and going to conflict, but I still want to see if Mike has the rest of them?

I do.  And really, as soon as the cpus4096 is safely set for 2.6.29 I can
devote much more time on it.

Thanks,
Mike

> 
> Thanks,
> Rusty.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: manual merge of the rr tree

[Ingo Molnar]

* Mike Travis <travis@sgi.com> wrote:

> Rusty Russell wrote:
> > On Monday 05 January 2009 23:17:45 Ingo Molnar wrote:
> >> That would allow Mike, Christoph and you to work this out cleanly from 
> >> scratch. It would also solve your merge conflict.
> >>
> >> Does that sound like a good solution?
> > 
> > Sure, but it won't make this window.  I guess since those patches 
> > don't do anything but lay groundwork it's not critical, but annoying 
> > they've lain fallow so long.
> > 
> > I'm happy to put them with the cpualloc patches, since they're related 
> > and going to conflict, but I still want to see if Mike has the rest of 
> > them?
> 
> I do.  And really, as soon as the cpus4096 is safely set for 2.6.29 I 
> can devote much more time on it.

I think the complete elimination of cpumask_t should be the primary 
priority - before jumping to any other aspect. If we dont get rid of it it 
will stick around forever, like the BKL. It was a nice migration helper 
but now it's time to wave goodbye? :)

	Ingo

Re: linux-next: manual merge of the rr tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Rusty,
> 
> On Mon, 5 Jan 2009 19:11:52 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote:
> >
> > On Monday 05 January 2009 14:02:39 Stephen Rothwell wrote:
> > > Similarly with init/main.c, include/linux/percpu.h,
> > > include/asm-generic/percpu.h and arch/x86/include/asm/percpu.h (though
> > > against different commits/trees, of course).
> > 
> > OK, here's the merge as I did it.  I've also attached a tarball of the files
> > post-merge.
> 
> Sorry to put you to all this work, but Ingo has rendered it unneeded by 
> dropping the other patches.

Yeah, and dont be afraid to ask for it: i can either zap a full topic, or 
people can pull from it in the Git space. Merging code in a friendly way 
is generally far easier than letting complex conflicts happen and stacking 
trees on each other in a conflicting way.

This is generally one of the big advantages of a Git based topical setup - 
we were able to discard a portion of development history that turned out 
to go nowhere in its current form - without any collateral damage. (And 
the history was non-trivial - it went back almost a year.)

	Ingo

Re: linux-next: manual merge of the rr tree

[Mike Travis]

Ingo Molnar wrote:
> * Mike Travis <travis@sgi.com> wrote:
> 
>> Rusty Russell wrote:
>>> On Monday 05 January 2009 23:17:45 Ingo Molnar wrote:
>>>> That would allow Mike, Christoph and you to work this out cleanly from 
>>>> scratch. It would also solve your merge conflict.
>>>>
>>>> Does that sound like a good solution?
>>> Sure, but it won't make this window.  I guess since those patches 
>>> don't do anything but lay groundwork it's not critical, but annoying 
>>> they've lain fallow so long.
>>>
>>> I'm happy to put them with the cpualloc patches, since they're related 
>>> and going to conflict, but I still want to see if Mike has the rest of 
>>> them?
>> I do.  And really, as soon as the cpus4096 is safely set for 2.6.29 I 
>> can devote much more time on it.
> 
> I think the complete elimination of cpumask_t should be the primary 
> priority - before jumping to any other aspect. If we dont get rid of it it 
> will stick around forever, like the BKL. It was a nice migration helper 
> but now it's time to wave goodbye? :)
> 
> 	Ingo

I think that's possible for 2.6.30 especially with Rusty's "big hammer"
patch that removes the definition of cpumask_t.  Of course, as has been
the delay forever, is dealing with all the arch's.  The current method
of some via tip, some via linux-next/rr has been somewhat excruciating.
How about we push the big ones via -mm so we get more complaints early on?

Or some other suggestion?  Once the "big hammer" patch is in, there will
be massive fallout, and I plan on being on an extended vacation when that
happens... ;-)

Thanks,
Mike

Re: linux-next: manual merge of the rr tree

[Ingo Molnar]

* Mike Travis <travis@sgi.com> wrote:

> Ingo Molnar wrote:
> > * Mike Travis <travis@sgi.com> wrote:
> > 
> >> Rusty Russell wrote:
> >>> On Monday 05 January 2009 23:17:45 Ingo Molnar wrote:
> >>>> That would allow Mike, Christoph and you to work this out cleanly from 
> >>>> scratch. It would also solve your merge conflict.
> >>>>
> >>>> Does that sound like a good solution?
> >>> Sure, but it won't make this window.  I guess since those patches 
> >>> don't do anything but lay groundwork it's not critical, but annoying 
> >>> they've lain fallow so long.
> >>>
> >>> I'm happy to put them with the cpualloc patches, since they're related 
> >>> and going to conflict, but I still want to see if Mike has the rest of 
> >>> them?
> >> I do.  And really, as soon as the cpus4096 is safely set for 2.6.29 I 
> >> can devote much more time on it.
> > 
> > I think the complete elimination of cpumask_t should be the primary 
> > priority - before jumping to any other aspect. If we dont get rid of it it 
> > will stick around forever, like the BKL. It was a nice migration helper 
> > but now it's time to wave goodbye? :)
> > 
> > 	Ingo
> 
> I think that's possible for 2.6.30 especially with Rusty's "big hammer" 
> patch that removes the definition of cpumask_t.  Of course, as has been 
> the delay forever, is dealing with all the arch's.  The current method 
> of some via tip, some via linux-next/rr has been somewhat excruciating. 
> How about we push the big ones via -mm so we get more complaints early 
> on?

Sure, can do it via -mm or via -tip/cpus4096.

> Or some other suggestion?  Once the "big hammer" patch is in, there will 
> be massive fallout, and I plan on being on an extended vacation when 
> that happens... ;-)

hm, on a second thought, lets do it via -mm only ;-)

	Ingo

Re: linux-next: manual merge of the rr tree

[Christoph Lameter]

yOn Tue, 6 Jan 2009, Rusty Russell wrote:

> It was a Richard Henderson thing.  It was over six years ago, but I found
> one decent reference to it:
>
> 	http://lwn.net/2002/0214/a/per-cpu.php3
>
> Hope that answers your question?

Well thats the patch you sent in to Linus. I see one relevant comment in
there:

+/* This macro obfuscates arithmetic on a variable address so that gcc
+   shouldn't recognize it. This prevents optimizations such as the
+   famous:
+	strcpy(s, "xxx"+X) => memcpy(s, "xxx"+X, 4-X) */
+#define reloc_hide(var, off)						\
+  ({ __typeof__(&(var)) __ptr;					\
+    __asm__ ("" : "=g"(__ptr) : "0"((void *)&(var) + (off)));	\
+    *__ptr; })


I dont get the point here.

strcpy(s, "xxx" + X ) -> memcpy(s, "xxx" + X, strlen("xxx" + X) + 1) -> memcpy(s, "xxx" + X, 4 - X)

So far okay.

The problem is the adding of an offset to a variable? X is the per cpu
offset?

Strings are not put into per cpu areas by the compiler so this example
here is not clear nor relevant to percpu issues.


Andi said a while back that the RELOC_HIDE macro exists because of
wrapping issues. http://lists.openwall.net/linux-kernel/2006/08/24/340.
That issue does not seem to be apply on x86 since signed and
unsigned additions are the same. Moreover zero based per cpu addresses
will avoid wrapping entirely.

Could we clearly document what the point of RELOC_HIDE is?

Re: linux-next: manual merge of the rr tree

[Rusty Russell]

On Wednesday 07 January 2009 00:51:20 Mike Travis wrote:
> Ingo Molnar wrote:
> > I think the complete elimination of cpumask_t should be the primary 
> > priority - before jumping to any other aspect. If we dont get rid of it it 
> > will stick around forever, like the BKL. It was a nice migration helper 
> > but now it's time to wave goodbye? :)
> > 
> > 	Ingo
> 
> I think that's possible for 2.6.30 especially with Rusty's "big hammer"
> patch that removes the definition of cpumask_t.

I have two config option patches.  One removes the old deprecated ops.  This
almost compiles now.  The other removes the struct cpumask and cpumask_t
definitions.  This breaks horribly.  Wading through that is on my TODO.

cpus_allowed in task_struct is fairly nasty.  We'll introduce an accessor
macro for that one I think since it's widespread (a "big hammer" is going to
kill us all if we try it!).

But I agree that we should get to that goal as fast as possible; it's the
only real way to stop people introducing onstack cpumasks, copying them, etc.

Cheers,
Rusty.

Re: linux-next: manual merge of the rr tree

[Rusty Russell]

On Wednesday 07 January 2009 01:35:57 Christoph Lameter wrote:
> +/* This macro obfuscates arithmetic on a variable address so that gcc
> +   shouldn't recognize it. This prevents optimizations such as the
> +   famous:
> +	strcpy(s, "xxx"+X) => memcpy(s, "xxx"+X, 4-X) */
> +#define reloc_hide(var, off)						\
> +  ({ __typeof__(&(var)) __ptr;					\
> +    __asm__ ("" : "=g"(__ptr) : "0"((void *)&(var) + (off)));	\
> +    *__ptr; })
> 
> I dont get the point here.

This one example of gcc making assumptions about pointer arithmetic.  It's
perfectly reasonable.  It's also unhelpful cases like for per-cpu offsets.

Thus we use this macro to prevent GCC from making such assumptions.

We can't audit current and future gcc versions to see what other
optimizations might break our code on every arch.  I just documented it,
and followed Richard's advice.

Am I missing a downside?

> Could we clearly document what the point of RELOC_HIDE is?

Sorry, I'm not sure I can improve on the current comment:

/* This macro obfuscates arithmetic on a variable address so that gcc
   shouldn't recognize the original var, and make assumptions about it */

Cheers,
Rusty.

Re: linux-next: manual merge of the rr tree

[Christoph Lameter]

On Wed, 7 Jan 2009, Rusty Russell wrote:

> > +   famous:
> > +	strcpy(s, "xxx"+X) => memcpy(s, "xxx"+X, 4-X) */
> > +#define reloc_hide(var, off)						\
> > +  ({ __typeof__(&(var)) __ptr;					\
> > +    __asm__ ("" : "=g"(__ptr) : "0"((void *)&(var) + (off)));	\
> > +    *__ptr; })
> >
> > I dont get the point here.
>
> This one example of gcc making assumptions about pointer arithmetic.  It's
> perfectly reasonable.  It's also unhelpful cases like for per-cpu offsets.

What assumption does GCC make that would cause problems?

> Thus we use this macro to prevent GCC from making such assumptions.

Never seen any ill effect from just using a pointer recast and add.

> We can't audit current and future gcc versions to see what other
> optimizations might break our code on every arch.  I just documented it,
> and followed Richard's advice.
>
> Am I missing a downside?

GCC cannot optimize the pointer arithmetic with the strange asm code. It
seems that no one really knows what the exact purpose of RELOC_HIDE is.

One issue may be that issue of pointer into an object not being valid if
they are made to point outside of the object?

> > Could we clearly document what the point of RELOC_HIDE is?
>
> Sorry, I'm not sure I can improve on the current comment:
>
> /* This macro obfuscates arithmetic on a variable address so that gcc
>    shouldn't recognize the original var, and make assumptions about it */

What assumptions? Obviously you still want the linker relocation to
happen.

Re: linux-next: manual merge of the rr tree

[Andi Kleen]

> > This one example of gcc making assumptions about pointer arithmetic.  It's
> > perfectly reasonable.  It's also unhelpful cases like for per-cpu offsets.
> 
> What assumption does GCC make that would cause problems?

The C standard says that arithmetic on pointers in defined objects outside
the boundaries of these objects (except for the special case of one beyond 
the end for arrays) is undefined. The gcc optimizers take advantage
of this by assuming that such arithmetic doesn't wrap (and might have other
assumptions)

> 
> > Thus we use this macro to prevent GCC from making such assumptions.
> 
> Never seen any ill effect from just using a pointer recast and add.

One concrete miscompilation has been observed on PPC a couple
of years ago, so it was decided to try to avoid this on all
architectures.
> 
> One issue may be that issue of pointer into an object not being valid if
> they are made to point outside of the object?

"undefined" yes.

-Andi
-- 
ak@linux.intel.com

Re: linux-next: manual merge of the rr tree

[Christoph Lameter]

On Wed, 7 Jan 2009, Andi Kleen wrote:

> The C standard says that arithmetic on pointers in defined objects outside
> the boundaries of these objects (except for the special case of one beyond
> the end for arrays) is undefined. The gcc optimizers take advantage
> of this by assuming that such arithmetic doesn't wrap (and might have other
> assumptions)

Ok then we need to say so in a comment around RELOC_HIDE.

Re: linux-next: manual merge of the rr tree

[Andi Kleen]

On Wed, Jan 07, 2009 at 01:01:06PM -0600, Christoph Lameter wrote:
> On Wed, 7 Jan 2009, Andi Kleen wrote:
> 
> > The C standard says that arithmetic on pointers in defined objects outside
> > the boundaries of these objects (except for the special case of one beyond
> > the end for arrays) is undefined. The gcc optimizers take advantage
> > of this by assuming that such arithmetic doesn't wrap (and might have other
> > assumptions)
> 
> Ok then we need to say so in a comment around RELOC_HIDE.

Here's a patch to do that. Andrew, please add it.

-Andi

---


Add more comments to RELOC_HIDE

Requested by C. Lameter

Signed-off-by: Andi Kleen <ak@linux.intel.com>

---
 include/linux/compiler-gcc.h |   16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

Index: linux-2.6.28-test/include/linux/compiler-gcc.h
===================================================================
--- linux-2.6.28-test.orig/include/linux/compiler-gcc.h	2008-05-08 12:56:10.000000000 +0200
+++ linux-2.6.28-test/include/linux/compiler-gcc.h	2009-01-08 21:31:55.000000000 +0100
@@ -11,9 +11,19 @@
 /* The "volatile" is due to gcc bugs */
 #define barrier() __asm__ __volatile__("": : :"memory")
 
-/* This macro obfuscates arithmetic on a variable address so that gcc
-   shouldn't recognize the original var, and make assumptions about it */
-/*
+/*
+ * This macro obfuscates arithmetic on a variable address so that gcc
+ * shouldn't recognize the original var, and make assumptions about it.
+ *
+ * This is needed because the C standard makes it undefined to do
+ * pointer arithmetic on "objects" outside their boundaries and the
+ * gcc optimizers assume this is the case. In particular they
+ * assume such arithmetic does not wrap.
+ *
+ * A miscompilation has been observed because of this on PPC.
+ * To work around it we hide the relationship of the pointer and the object
+ * using this macro.
+ *
  * Versions of the ppc64 compiler before 4.1 had a bug where use of
  * RELOC_HIDE could trash r30. The bug can be worked around by changing
  * the inline assembly constraint from =g to =r, in this particular

-- 
ak@linux.intel.com

Re: linux-next: manual merge of the rr tree

[Andrew Morton]

On Thu, 8 Jan 2009 21:48:35 +0100
Andi Kleen <andi@firstfloor.org> wrote:

> +/*
> + * This macro obfuscates arithmetic on a variable address so that gcc
> + * shouldn't recognize the original var, and make assumptions about it.
> + *
> + * This is needed because the C standard makes it undefined to do
> + * pointer arithmetic on "objects" outside their boundaries and the
> + * gcc optimizers assume this is the case. In particular they
> + * assume such arithmetic does not wrap.
> + *
> + * A miscompilation has been observed because of this on PPC.
> + * To work around it we hide the relationship of the pointer and the object
> + * using this macro.
> + *

wow, thanks.  I always wondered.

Re: linux-next: manual merge of the rr tree

[Christoph Lameter]

This also then means that RELOC_HIDE can simply be pointer arithmetic on
non PPC, right?


Reviewed-by: Christoph Lameter <cl@linux-foundation.org>

Re: linux-next: manual merge of the rr tree

[Andi Kleen]

On Thu, Jan 08, 2009 at 03:15:48PM -0600, Christoph Lameter wrote:
> This also then means that RELOC_HIDE can simply be pointer arithmetic on
> non PPC, right?

No, the C standard and the gcc optimizer are the same on all architectures.

-Andi
-- 
ak@linux.intel.com

Re: linux-next: manual merge of the rr tree

[Christoph Lameter]

On Thu, 8 Jan 2009, Andi Kleen wrote:

> On Thu, Jan 08, 2009 at 03:15:48PM -0600, Christoph Lameter wrote:
> > This also then means that RELOC_HIDE can simply be pointer arithmetic on
> > non PPC, right?
>
> No, the C standard and the gcc optimizer are the same on all architectures.

The wrapping is okay on platforms that use straight 2 complement without
additional tricks in high bits. Some platforms do not wrap.

No need to stop the cc optimizer from optimizing pointer addition there.
The C compiler can generate more effective code if we do not go through
this asm segment. See how RELOC_HIDE is defined for the icc and
in include/linux/gcc.h.

Also: Would it not be better to rename RELOC_HIDE. To
ADD_POINTER_OFFSET_BEYOND_OBJECT_BOUNDARY or so?

What are the following uses of RELOC_HIDE to add a zero offset. Certainly
they have nothing to do with wrapping.

arch/mips/include/asm/page.h:#define __pa_symbol(x)
__pa(RELOC_HIDE((unsigned long)(x), 0))
arch/sh/include/asm/system.h:   struct pt_regs *regs = RELOC_HIDE(&__regs,
0);  \
arch/x86/include/asm/page_32.h:#define __phys_reloc_hide(x)
RELOC_HIDE((x), 0)

Guess we assume that GCC is passing some magic with a pointer that is
not lost when casting it?

What kind of magical properties are these? Address invalidation is messed
up in gcc and just icc does it right?

Re: linux-next: manual merge of the rr tree

[David Miller]

From: Christoph Lameter <cl@linux-foundation.org>
Date: Thu, 8 Jan 2009 16:21:32 -0600 (CST)

> On Thu, 8 Jan 2009, Andi Kleen wrote:
> 
> > On Thu, Jan 08, 2009 at 03:15:48PM -0600, Christoph Lameter wrote:
> > > This also then means that RELOC_HIDE can simply be pointer arithmetic on
> > > non PPC, right?
> >
> > No, the C standard and the gcc optimizer are the same on all architectures.
> 
> The wrapping is okay on platforms that use straight 2 complement without
> additional tricks in high bits. Some platforms do not wrap.

It's not okay for loop termination conditions and that's where GCC
takes advantage of this invariant.

Otherwise, if overflow is possible, tranforming an array index
comparison into a pointer comparison is no longer legal.

linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
arch/powerpc/kernel/sysfs.c between commit
93197a36a9c16a85fb24cf5a8639f7bf9af838a3 ("powerpc: Rewrite sysfs
processor cache info code") from Linus' tree and commit
013ab448cec493262080ecc47b13e0adbcfaeccd ("cpualloc:rename-per_cpu-vars")
from the rr tree.

The former moved the code modified by the latter into another file and
rewrote it.  This is part of the code churn that should not be happening
in linux-next during the merge window.  :-(

I have dropped the rr tree for today, sorry.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: manual merge of the rr tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
arch/powerpc/kernel/sysfs.c between commit
93197a36a9c16a85fb24cf5a8639f7bf9af838a3 ("powerpc: Rewrite sysfs
processor cache info code") from Linus' tree and commit
013ab448cec493262080ecc47b13e0adbcfaeccd ("cpualloc:rename-per_cpu-vars")
from the rr tree.

The former moved the code modified by the latter into another file and
rewrote it.  This is part of the code churn that should not be happening
in linux-next during the merge window.  :-(

I have dropped the rr tree for today, sorry.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: manual merge of the rr tree

[Christoph Lameter]

On Thu, 8 Jan 2009, David Miller wrote:

> > The wrapping is okay on platforms that use straight 2 complement without
> > additional tricks in high bits. Some platforms do not wrap.
>
> It's not okay for loop termination conditions and that's where GCC
> takes advantage of this invariant.

Can you give me a concrete code example?

> Otherwise, if overflow is possible, tranforming an array index
> comparison into a pointer comparison is no longer legal.

This means that access to an object immediately before or after would wrap
around. If the object is not near 0 or near the end of the address space
then such a thing cannot occur. We have the ZERO page at address 0 so the
lower end is taken care and usually there are also special uses for very
high addresses.

The wrapping is mainly an issue if the percpu area is linked to very high
addresses but later the per cpu areas for the individual processors are
allocated on relatively low addresses. The address calculation of the
location of a percpu address for a particular cpu then occurs by
adding an offset that will wrap around zero. This is fine on x86.

Re: linux-next: manual merge of the rr tree

[David Miller]

From: Christoph Lameter <cl@linux-foundation.org>
Date: Fri, 9 Jan 2009 08:42:09 -0600 (CST)

> On Thu, 8 Jan 2009, David Miller wrote:
> 
> > Otherwise, if overflow is possible, tranforming an array index
> > comparison into a pointer comparison is no longer legal.
> 
> This means that access to an object immediately before or after would wrap
> around. If the object is not near 0 or near the end of the address space
> then such a thing cannot occur. We have the ZERO page at address 0 so the
> lower end is taken care and usually there are also special uses for very
> high addresses.

GCC, or any compiler, cannot know about such invariants.
What it does know is that it can always transform
comparisons between "i" and "max_i" into comparisons
between '&array[i]' and '&array[max_i]'

> The wrapping is mainly an issue if the percpu area is linked to very high
> addresses but later the per cpu areas for the individual processors are
> allocated on relatively low addresses. The address calculation of the
> location of a percpu address for a particular cpu then occurs by
> adding an offset that will wrap around zero. This is fine on x86.

Anyways, the original reason for the RELOC_HIDE business is that GCC
would do common subexpression elimination on the address computation.
The percpu stuff was a calculation using a symbol address as some kind
of base, and GCC took liberties with that (which were legal given
the amount of information we (weren't) giving to it).

I honestly forget the exact details, I'm sure Rusty could explain...