linux-next: manual merge of the rr tree

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

[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

[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

[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

[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

[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

[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

[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.

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

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

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]

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

[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

[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

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]

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();

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

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

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

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.

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

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

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]

[-- 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 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: 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
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: 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 --]

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.

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

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

[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

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;
  }

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

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.

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]

[-- 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]

[-- 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: 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: 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: 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: 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: 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 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.

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.

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

[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: 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 --]

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.