linux-next: manual merge of the kmemcheck tree

linux-next: manual merge of the kmemcheck tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the kmemcheck tree got a trivial conflict in
arch/x86/kernel/traps_32.c between commit
6ac8d51f01d345af5ea4209004a9ea29b2f20891 ("x86: introducing
asm-x86/traps.h") from Linus' tree and commit
787ecfaa503dc63ff1831ddc74b15dad49bace1d ("x86: add hooks for kmemcheck")
from the kmemcheck tree.

Just overlapping additions of includes.  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 --]

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

[Ingo Molnar]

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

> Hi all,
> 
> Today's linux-next merge of the kmemcheck tree got a trivial conflict in
> arch/x86/kernel/traps_32.c between commit
> 6ac8d51f01d345af5ea4209004a9ea29b2f20891 ("x86: introducing
> asm-x86/traps.h") from Linus' tree and commit
> 787ecfaa503dc63ff1831ddc74b15dad49bace1d ("x86: add hooks for kmemcheck")
> from the kmemcheck tree.
> 
> Just overlapping additions of includes.  I can carry it.

thanks Stephen - i had this conflict fixup too in tip/master but not yet 
in auto-kmemcheck-next. I've now propagated it so the conflict should go 
away on your next integration run.

	Ingo

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

[Stephen Rothwell]

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

Hi Ingo,

On Tue, 22 Jul 2008 08:52:11 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> thanks Stephen - i had this conflict fixup too in tip/master but not yet 
> in auto-kmemcheck-next. I've now propagated it so the conflict should go 
> away on your next integration run.

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 kmemcheck tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kmemcheck tree got a conflict in
mm/slub.c between commit 773ff60e841461cb1f9374a713ffcda029b8c317 ("SLUB:
failslab support") from the slab tree and commit
18fd427debcf37c06917b55295df682fd05fee76 ("slub: add hooks for
kmemcheck") from the kmemcheck tree.

I fixed it up (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 mm/slub.c
index f0e2892,df12f28..0000000
--- a/mm/slub.c
+++ b/mm/slub.c
@@@ -24,7 -24,7 +24,8 @@@
  #include <linux/kallsyms.h>
  #include <linux/memory.h>
  #include <linux/math64.h>
 +#include <linux/fault-inject.h>
+ #include <linux/kmemcheck.h>
  
  /*
   * Lock order:

linux-next: manual merge of the kmemcheck tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kmemcheck tree got a conflict in
mm/Makefile between commit 773ff60e841461cb1f9374a713ffcda029b8c317
("SLUB: failslab support") from the slab tree and commit
e6df1035b1b488cafde1e69f1a25f2706c3ac1f7 ("kmemcheck: add mm functions")
from the kmemcheck tree.

I fixed it up (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 mm/Makefile
index 51c2770,399aaf1..0000000
--- a/mm/Makefile
+++ b/mm/Makefile
@@@ -28,7 -28,7 +28,8 @@@ obj-$(CONFIG_SLOB) += slob.
  obj-$(CONFIG_MMU_NOTIFIER) += mmu_notifier.o
  obj-$(CONFIG_SLAB) += slab.o
  obj-$(CONFIG_SLUB) += slub.o
 +obj-$(CONFIG_FAILSLAB) += failslab.o
+ obj-$(CONFIG_KMEMCHECK) += kmemcheck.o
  obj-$(CONFIG_MEMORY_HOTPLUG) += memory_hotplug.o
  obj-$(CONFIG_FS_XIP) += filemap_xip.o
  obj-$(CONFIG_MIGRATION) += migrate.o

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

[Ingo Molnar]

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

> Hi all,
> 
> Today's linux-next merge of the kmemcheck tree got a conflict in
> arch/x86/mm/Makefile between commit
> fd3fdf11d3c649769e02459c5f1b8081a15e9007 ("trace: add the MMIO-tracer to
> the tracer menu, cleanup") from the ftrace tree and commit
> 385e31b9eae0528bada07d16a189f3f40df23961 ("kmemcheck: add the kmemcheck
> core") from the kmemcheck tree.
> 
> Just context changes.  I fixed it (see below) and can carry the fix.

> +++ b/arch/x86/mm/Makefile
> @@@ -8,8 -8,11 +8,10 @@@ obj-$(CONFIG_X86_PTDUMP)	+= dump_pageta
>   
>   obj-$(CONFIG_HIGHMEM)		+= highmem_32.o
>   
> + obj-$(CONFIG_KMEMCHECK)		+= kmemcheck/
> + 
>  -obj-$(CONFIG_MMIOTRACE_HOOKS)	+= kmmio.o
>   obj-$(CONFIG_MMIOTRACE)		+= mmiotrace.o
>  -mmiotrace-y			:= pf_in.o mmio-mod.o
>  +mmiotrace-y			:= kmmio.o pf_in.o mmio-mod.o

thanks Stephen, that's the correct resolution i have as well.

	Ingo

linux-next: manual merge of the kmemcheck tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kmemcheck tree got a conflict in
arch/x86/mm/Makefile between commit
fd3fdf11d3c649769e02459c5f1b8081a15e9007 ("trace: add the MMIO-tracer to
the tracer menu, cleanup") from the ftrace tree and commit
385e31b9eae0528bada07d16a189f3f40df23961 ("kmemcheck: add the kmemcheck
core") from the kmemcheck tree.

Just context changes.  I fixed it (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/x86/mm/Makefile
index 0a21b7a,f4edb6e..0000000
--- a/arch/x86/mm/Makefile
+++ b/arch/x86/mm/Makefile
@@@ -8,8 -8,11 +8,10 @@@ obj-$(CONFIG_X86_PTDUMP)	+= dump_pageta
  
  obj-$(CONFIG_HIGHMEM)		+= highmem_32.o
  
+ obj-$(CONFIG_KMEMCHECK)		+= kmemcheck/
+ 
 -obj-$(CONFIG_MMIOTRACE_HOOKS)	+= kmmio.o
  obj-$(CONFIG_MMIOTRACE)		+= mmiotrace.o
 -mmiotrace-y			:= pf_in.o mmio-mod.o
 +mmiotrace-y			:= kmmio.o pf_in.o mmio-mod.o
  obj-$(CONFIG_MMIOTRACE_TEST)	+= testmmiotrace.o
  
  obj-$(CONFIG_NUMA)		+= numa_$(BITS).o

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

[Ingo Molnar]

* Vegard Nossum <vegard.nossum@gmail.com> wrote:

> On Tue, Oct 21, 2008 at 9:32 AM, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> >> Hi all,
> >>
> >> Today's linux-next merge of the kmemcheck tree got a conflict in
> >> kernel/sysctl.c between commit af936a1606246a10c145feac3770f6287f483f02
> >> ("vmscan: unevictable LRU scan sysctl") from Linus' tree and commit
> >> 385e31b9eae0528bada07d16a189f3f40df23961 ("kmemcheck: add the kmemcheck
> >> core") from the kmemcheck tree.
> >>
> >> Just overlapping additions (combined with a bad merge in the kmemcheck
> >> tree).  I fixed it up (see below).
> >
> > thanks!
> >
> >> [Ingo: it looks like commit 05416cc42ac7072f39bcff036485e2b0fc1da3a9
> >> ("Merge branch 'linus' into kmemcheck") in the kmemcheck tree merged
> >> the "rcutorture_runnable" sysctl into the wrong table.]
> >
> > hm, good spotting! Vegard, will you apply it to your tree? If kmemcheck
> > does not make it in in this cycle then maybe it's best to rebase it
> > shortly after -rc1 is released, to get rid of uglies like that?
> 
> I will apply it and send a pull request. Thanks :-)
> 
> You want to rebase all of kmemcheck on top of -rc1? Sure, we can do 
> it. There's been a lot of back-and-forth with the set_memory_4k()/PSE 
> stuff as well, I imagine the patch-set wouldn't look very nice to 
> somebody trying to follow the history. But isn't rebasing very evil?

it is, so lets avoid it if possible.

	Ingo

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

[Vegard Nossum]

On Tue, Oct 21, 2008 at 9:32 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi all,
>>
>> Today's linux-next merge of the kmemcheck tree got a conflict in
>> kernel/sysctl.c between commit af936a1606246a10c145feac3770f6287f483f02
>> ("vmscan: unevictable LRU scan sysctl") from Linus' tree and commit
>> 385e31b9eae0528bada07d16a189f3f40df23961 ("kmemcheck: add the kmemcheck
>> core") from the kmemcheck tree.
>>
>> Just overlapping additions (combined with a bad merge in the kmemcheck
>> tree).  I fixed it up (see below).
>
> thanks!
>
>> [Ingo: it looks like commit 05416cc42ac7072f39bcff036485e2b0fc1da3a9
>> ("Merge branch 'linus' into kmemcheck") in the kmemcheck tree merged
>> the "rcutorture_runnable" sysctl into the wrong table.]
>
> hm, good spotting! Vegard, will you apply it to your tree? If kmemcheck
> does not make it in in this cycle then maybe it's best to rebase it
> shortly after -rc1 is released, to get rid of uglies like that?

I will apply it and send a pull request. Thanks :-)

You want to rebase all of kmemcheck on top of -rc1? Sure, we can do
it. There's been a lot of back-and-forth with the set_memory_4k()/PSE
stuff as well, I imagine the patch-set wouldn't look very nice to
somebody trying to follow the history. But isn't rebasing very evil?


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036

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

[Ingo Molnar]

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

> Hi all,
> 
> Today's linux-next merge of the kmemcheck tree got a conflict in
> kernel/sysctl.c between commit af936a1606246a10c145feac3770f6287f483f02
> ("vmscan: unevictable LRU scan sysctl") from Linus' tree and commit
> 385e31b9eae0528bada07d16a189f3f40df23961 ("kmemcheck: add the kmemcheck
> core") from the kmemcheck tree.
> 
> Just overlapping additions (combined with a bad merge in the kmemcheck
> tree).  I fixed it up (see below).

thanks!

> [Ingo: it looks like commit 05416cc42ac7072f39bcff036485e2b0fc1da3a9 
> ("Merge branch 'linus' into kmemcheck") in the kmemcheck tree merged 
> the "rcutorture_runnable" sysctl into the wrong table.]

hm, good spotting! Vegard, will you apply it to your tree? If kmemcheck 
does not make it in in this cycle then maybe it's best to rebase it 
shortly after -rc1 is released, to get rid of uglies like that?

	Ingo

linux-next: manual merge of the kmemcheck tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kmemcheck tree got a conflict in
kernel/sysctl.c between commit af936a1606246a10c145feac3770f6287f483f02
("vmscan: unevictable LRU scan sysctl") from Linus' tree and commit
385e31b9eae0528bada07d16a189f3f40df23961 ("kmemcheck: add the kmemcheck
core") from the kmemcheck tree.

Just overlapping additions (combined with a bad merge in the kmemcheck
tree).  I fixed it up (see below).

[Ingo: it looks like commit 05416cc42ac7072f39bcff036485e2b0fc1da3a9
("Merge branch 'linus' into kmemcheck") in the kmemcheck tree merged the
"rcutorture_runnable" sysctl into the wrong table.]

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

diff --cc kernel/sysctl.c
index b3cc739,3383afd..0000000
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@@ -823,26 -825,17 +824,37 @@@ static struct ctl_table kern_table[] = 
  		.child		= key_sysctls,
  	},
  #endif
 +#ifdef CONFIG_RCU_TORTURE_TEST
 +	{
 +		.ctl_name       = CTL_UNNUMBERED,
 +		.procname       = "rcutorture_runnable",
 +		.data           = &rcutorture_runnable,
 +		.maxlen         = sizeof(int),
 +		.mode           = 0644,
 +		.proc_handler   = &proc_dointvec,
 +	},
 +#endif
 +#ifdef CONFIG_UNEVICTABLE_LRU
 +	{
 +		.ctl_name	= CTL_UNNUMBERED,
 +		.procname	= "scan_unevictable_pages",
 +		.data		= &scan_unevictable_pages,
 +		.maxlen		= sizeof(scan_unevictable_pages),
 +		.mode		= 0644,
 +		.proc_handler	= &scan_unevictable_handler,
 +	},
 +#endif
+ #ifdef CONFIG_KMEMCHECK
+ 	{
+ 		.ctl_name	= CTL_UNNUMBERED,
+ 		.procname	= "kmemcheck",
+ 		.data		= &kmemcheck_enabled,
+ 		.maxlen		= sizeof(int),
+ 		.mode		= 0644,
+ 		.proc_handler	= &proc_dointvec,
+ 	},
+ #endif
+ 
  /*
   * NOTE: do not add new entries to this table unless you have read
   * Documentation/sysctl/ctl_unnumbered.txt

linux-next: manual merge of the kmemcheck tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kmemcheck tree got a conflict in
include/linux/mm_types.h between commit
52d4b9ac0b985168009c2a57098324e67bae171f ("memcg: allocate all
page_cgroup at boot") from Linus' tree and commit
385e31b9eae0528bada07d16a189f3f40df23961 ("kmemcheck: add the kmemcheck
core") from the kmemcheck tree.

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

diff --cc include/linux/mm_types.h
index fe82547,bca924a..0000000
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@@ -94,6 -94,13 +94,10 @@@ struct page 
  	void *virtual;			/* Kernel virtual address (NULL if
  					   not kmapped, ie. highmem) */
  #endif /* WANT_PAGE_VIRTUAL */
 -#ifdef CONFIG_CGROUP_MEM_RES_CTLR
 -	unsigned long page_cgroup;
 -#endif
+ 
+ #ifdef CONFIG_KMEMCHECK
+ 	void *shadow;
+ #endif
  };
  
  /*

linux-next: manual merge of the kmemcheck tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kmemcheck tree got a trivial conflict in
mm/slub.c between commit e63352fa06fb8c476e56e51323d80f2e7baee67f
("kmemtrace: SLUB hooks") from the slab tree and commit
18fd427debcf37c06917b55295df682fd05fee76 ("slub: add hooks for
kmemcheck") from the kmemcheck tree.

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

diff --cc mm/slub.c
index 141a590,5d15933..0000000
--- a/mm/slub.c
+++ b/mm/slub.c
@@@ -23,7 -23,7 +23,8 @@@
  #include <linux/kallsyms.h>
  #include <linux/memory.h>
  #include <linux/math64.h>
 +#include <linux/kmemtrace.h>
+ #include <linux/kmemcheck.h>
  
  /*
   * Lock order:

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

[Ingo Molnar]

* Pekka Enberg <penberg@cs.helsinki.fi> wrote:

> Stephen Rothwell wrote:
>> Today's linux-next merge of the kmemcheck tree got a conflict in
>> arch/x86/kernel/process_64.c between commits
>> 8092c654de9a964c14d89da56834f73a80548a58 ("x86: add KERN_INFO to printks
>> on process_64.c") and 7de08b4e1ed8d80e6086f71b7e99fc4b397aae39 ("x86:
>> coding styles fixes to arch/x86/kernel/process_64.c") from the x86 tree
>> and commit afdb7023b849cffda679fcec324ff592d7b24a51 ("x86:
>> __show_registers() and __show_regs() API unification") from the kmemcheck
>> tree.
>
> Ingo, can we push the unification patch to mainline before kmemcheck 
> to get rid of the conflict?

hm, i think it's too late for that. The 130+ arch/x86 contributors were 
very busy in this cycle too [1300+ commits (!)] so we need to slow down 
during -rc's much harder and much sooner than other, lower-flux 
subsystems.

Furthermore, this particular piece of code is not in a high-flux area so 
git-rerere should properly take care of it i think, even in the longer 
run. I've been carrying that merge fixup in tip/master for a long time.

	Ingo

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

[Stephen Rothwell]

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

Hi Vegard,

On Fri, 15 Aug 2008 09:04:08 +0200 "Vegard Nossum" <vegard.nossum@gmail.com> wrote:
>
> Just out of curiosity: Do you have a script that produces these
> messages? How hard would it be to include the "merge patch" (conflict
> resolution) itself in this e-mail?

I do use a script, but I start the email before I figure out what the
actual conflict and resolution are so I can fill in the details as I find
them.

> I think that would be a very helpful addition (if it can be done with
> no hassle on your side), because it means that I could actually look
> over it and give a comment if it looks wrong (with no hassle on my
> side, looking up the merge commit, etc.).

I'll see what I can do.  It shouldn't be to hard.

> But if it can't be done easily, then don't bother. The issues are
> mostly trivial anyway. Thanks for doing this work!

The really trivial ones usually end up with nothing in the resolution
diff as I take the commit from one or other tree, so I will leave those
out.

-- 
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 kmemcheck tree

[Vegard Nossum]

On Fri, Aug 15, 2008 at 8:49 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the kmemcheck tree got a conflict in
> arch/x86/kernel/traps_64.c between commit
> 4df9e510a9fda29aca71d8acac853b98aa6884d1 ("x86: coding style fixes to
> arch/x86/kernel/traps_64.c") from the x86 tree and commit
> 862849a36e6087faac6349de0b1bcc66ff98411b ("x86: add hooks for kmemcheck
> on x86_64") from the kmemcheck tree.
>
> All the includes got rearranged ... I fixed it up.

Hi Stephen,

Just out of curiosity: Do you have a script that produces these
messages? How hard would it be to include the "merge patch" (conflict
resolution) itself in this e-mail?

I think that would be a very helpful addition (if it can be done with
no hassle on your side), because it means that I could actually look
over it and give a comment if it looks wrong (with no hassle on my
side, looking up the merge commit, etc.).

But if it can't be done easily, then don't bother. The issues are
mostly trivial anyway. Thanks for doing this work!


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036

linux-next: manual merge of the kmemcheck tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the kmemcheck tree got a conflict in
arch/x86/kernel/process_64.c between commits
8092c654de9a964c14d89da56834f73a80548a58 ("x86: add KERN_INFO to printks
on process_64.c") and 7de08b4e1ed8d80e6086f71b7e99fc4b397aae39 ("x86:
coding styles fixes to arch/x86/kernel/process_64.c") from the x86 tree
and commit afdb7023b849cffda679fcec324ff592d7b24a51 ("x86:
__show_registers() and __show_regs() API unification") from the kmemcheck
tree.

I fixed them up as was pretty obvious.

-- 
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 kmemcheck tree

[Pekka Enberg]

Stephen Rothwell wrote:
> Today's linux-next merge of the kmemcheck tree got a conflict in
> arch/x86/kernel/process_64.c between commits
> 8092c654de9a964c14d89da56834f73a80548a58 ("x86: add KERN_INFO to printks
> on process_64.c") and 7de08b4e1ed8d80e6086f71b7e99fc4b397aae39 ("x86:
> coding styles fixes to arch/x86/kernel/process_64.c") from the x86 tree
> and commit afdb7023b849cffda679fcec324ff592d7b24a51 ("x86:
> __show_registers() and __show_regs() API unification") from the kmemcheck
> tree.

Ingo, can we push the unification patch to mainline before kmemcheck to 
get rid of the conflict?

		Pekka

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

[Ingo Molnar]

* Pekka Enberg <penberg@cs.helsinki.fi> wrote:

> On Wed, 2008-08-13 at 13:52 +0200, Ingo Molnar wrote:
> > seems pretty sane to me. We use something quite similar in -tip, with 
> > the distinction that after a very short initial period [a few days at 
> > most] we try to keep development branches append-only as well.
> 
> Sure, I try to do that as well. But like I said, I've had a lot of 
> churn coming from the defrag patches recently...
> 
> But how do you deal with reverts, btw? Assuming you have a patch that 
> you've pushed out already but not asked Linus to pull, what do you do? 
> I currently use git-rebase -i and just drop the patch completely.

it depends - if the patch is the last one, i can just reset the topic 
back to just before that patch. If it's not, i use git-revert.

But the best way to deal with reverts is to use enough topic branches so 
that there's no 'mixing' between independent topics. Most reverts happen 
because there's some testing problem - so i do the revert in the 
_integration_ branch, not in the topic branch, and wait for the fix. 
Once the fix is available, it will be applied to the topic branch and 
the revert is dropped from the integration branch.

Worst-case i have to disable a full topic from the integration branch - 
but even in that case the topic commits still sit in the topic branch 
append-only and are waiting for the fix to arrive. One more detail: if a 
topic branch is broken i try not to merge upstream -rc's into that 
branch, to not artificially widen the window of breakage that could 
break bisection.

	Ingo

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

[Pekka Enberg]

On Wed, 2008-08-13 at 13:52 +0200, Ingo Molnar wrote:
> seems pretty sane to me. We use something quite similar in -tip, with 
> the distinction that after a very short initial period [a few days at 
> most] we try to keep development branches append-only as well.

Sure, I try to do that as well. But like I said, I've had a lot of churn
coming from the defrag patches recently...

But how do you deal with reverts, btw? Assuming you have a patch that
you've pushed out already but not asked Linus to pull, what do you do? I
currently use git-rebase -i and just drop the patch completely.

		Pekka

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

[Ingo Molnar]

* Pekka Enberg <penberg@cs.helsinki.fi> wrote:

> Hi Ingo,
> 
> On Wed, 2008-08-13 at 10:58 +0200, Ingo Molnar wrote:
> > what's your current workflow, what causes the sha1's for commits to 
> > change frequently? Do you work with patches (i.e. it's not really a Git 
> > workflow at all and you regenerate the git tree all the time you export 
> > it from your patch queue), or do you perhaps git-rebase often to clean 
> > up patches?
> 
> No, I don't work with patches. A lot of the churn comes from the fact 
> that I have been dropping and re-applying SLUB defrag patches from 
> Christoph lately. I keep them in a topic branch and pull them for my 
> 'for-next' branch that appears in linux-next.
> 
> The basic workflow for me is as follows:
> 
>   - Whenever someone sends me a patch, I apply it to my 'testing' 
>     branch, do a little bit testing there and if everything seems fine,
>     I pull the branch to my 'for-next' branch.
> 
>   - After few days, I pull (or cherry pick) the patches to 'for-linus' 
>     branch and ask Linus to pull. Whenever he pulls, I usually rebase 
>     all of my branches to Linus' master.
> 
>   - For development, I maintain topic branches that are _not_ 
>     append-only (such as SLUB defrag and kmemtrace). Whenever something 
>     changes there I do a git-reset --hard on 'for-next' and re-pull the 
>     topic branches there.
> 
>   - Also, I usually rebase my whole tree after an -rc release or two 
>     just to keep my tree in-sync with mainline. That usually doesn't 
>     affect my patches at all.
> 
> So AFAICT most of the changes to SHA1s are due to me doing development 
> in the topic branches and recreating the 'for-next' branch.

seems pretty sane to me. We use something quite similar in -tip, with 
the distinction that after a very short initial period [a few days at 
most] we try to keep development branches append-only as well.

There are 5 main advantages of doing that:

- trust: the end result, despite being a slighly bit messy, is easier to 
  trust. The commits are in true historic order, development activities 
  and timeline is easy to review.

- integration: creating the next branch is just a matter of doing an 
  incremental git-merge.

- guaranteed no-brains preservation of information: no patch is lost 
  ever in a pure append-only flow. Doing a git-reset --hard anytime 
  always risks the loss of patches - and even if only history is lost, 
  that is valuable too most of the time. Whenever i do it i have to use 
  additional safeguards against the loss of patches.

- bisection quality: statistically, the newest commits tend to have
  the most bugs. By doing delta patches - even if the end result is a 
  higher patch count - makes the risky portion of a stream of 
  append-only changes drastically smaller. [this assumes that there is 
  an adequate QA effort and that commits do not just sit there unused: 
  that the topic branch is tested well enough and is exposed to others 
  via linux-next, etc.]

- other contributors: derived work (people basing trees off topic 
  branches) do not get sha1's pulled from under their feet. Back/forth 
  merging is easy. Having history of development in a tree (as long as 
  it's not totally insane history) is beneficial in general.

btw., when you send something to Linus and he pulls, generally you dont 
have to rebase/reset to 'clean up the house' - as long as you dont 
cherry-pick into the release branch. A "git-merge linus/master" will 
fast-forward your topic branch and will turn it into a pure 
upstream-based branch.

	Ingo

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

[Pekka Enberg]

Hi Ingo,

On Wed, 2008-08-13 at 10:58 +0200, Ingo Molnar wrote:
> what's your current workflow, what causes the sha1's for commits to 
> change frequently? Do you work with patches (i.e. it's not really a Git 
> workflow at all and you regenerate the git tree all the time you export 
> it from your patch queue), or do you perhaps git-rebase often to clean 
> up patches?

No, I don't work with patches. A lot of the churn comes from the fact
that I have been dropping and re-applying SLUB defrag patches from
Christoph lately. I keep them in a topic branch and pull them for my
'for-next' branch that appears in linux-next.

The basic workflow for me is as follows:

  - Whenever someone sends me a patch, I apply it to my 'testing' 
    branch, do a little bit testing there and if everything seems fine,
    I pull the branch to my 'for-next' branch.

  - After few days, I pull (or cherry pick) the patches to 'for-linus' 
    branch and ask Linus to pull. Whenever he pulls, I usually rebase 
    all of my branches to Linus' master.

  - For development, I maintain topic branches that are _not_ 
    append-only (such as SLUB defrag and kmemtrace). Whenever something 
    changes there I do a git-reset --hard on 'for-next' and re-pull the 
    topic branches there.

  - Also, I usually rebase my whole tree after an -rc release or two 
    just to keep my tree in-sync with mainline. That usually doesn't 
    affect my patches at all.

So AFAICT most of the changes to SHA1s are due to me doing development
in the topic branches and recreating the 'for-next' branch.

		Pekka

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

[Ingo Molnar]

* Pekka Enberg <penberg@cs.helsinki.fi> wrote:

> Hi Ingo,
> 
> On Wed, 2008-08-13 at 09:58 +0200, Ingo Molnar wrote:
> > (This would be doable and pretty painless as long as slab.git is
> > purely append-only and not rebased.)
> 
> Heh, it's not, as I never quite understood the workflow for that. But 
> that's another discussion, I suppose.

what's your current workflow, what causes the sha1's for commits to 
change frequently? Do you work with patches (i.e. it's not really a Git 
workflow at all and you regenerate the git tree all the time you export 
it from your patch queue), or do you perhaps git-rebase often to clean 
up patches?

	Ingo

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

[Pekka Enberg]

Hi Ingo,

On Wed, 2008-08-13 at 09:58 +0200, Ingo Molnar wrote:
> (This would be doable and pretty painless as long as slab.git is
> purely append-only and not rebased.)

Heh, it's not, as I never quite understood the workflow for that. But
that's another discussion, I suppose.

		Pekka

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

[Ingo Molnar]

* Pekka Enberg <penberg@cs.helsinki.fi> wrote:

> Ingo Molnar wrote:
>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>>> Hi all,
>>>
>>> Today's linux-next merge of the kmemcheck tree got a conflict in
>>> mm/slab.c between commit fccd5095804ffc190cb2371c319cb4f5b2c0ee14
>>> ("kmemtrace: SLAB hooks") from the slab tree and commit
>>> 30532cb3c49a2a9fed94127aab26003c52398a51 ("slab: add hooks for
>>> kmemcheck") from the kmemcheck tree.
>>>
>>> Simply overlapping additions of includes.
>>
>> thanks Stephen! I suspect these resolutions will live in linux-next for 
>> the next 2 months, as that's the soonest there will be a natural merge  
>> between slab.git and tip/kmemcheck.
>
> Oh, I was just asking Stephen what to do with those. If the 
> resolutions can be in linux-next, I'm fine with that.

yep, that's the best i think. I dont think we want to couple the two 
trees.

If it ever becomes hard we could start tracking your slab.git in -tip 
and auto-merge it all into auto-kmemcheck-next and make sure kmemcheck 
branch is merged in linux-next after slab.git is merged, and thus 
offload the conflict resolutions from Stephen to the people who actually 
generate the conflicts :-) (This would be doable and pretty painless as 
long as slab.git is purely append-only and not rebased.)

	Ingo

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

[Stephen Rothwell]

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

Hi Ingo,

On Wed, 13 Aug 2008 09:32:05 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> thanks Stephen! I suspect these resolutions will live in linux-next for 
> the next 2 months, as that's the soonest there will be a natural merge 
> between slab.git and tip/kmemcheck.

Yeah, I guess so as well.  However, they are only trivial conflicts, so
no real problem.

-- 
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 kmemcheck tree

[Ingo Molnar]

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

> Hi all,
> 
> Today's linux-next merge of the kmemcheck tree got a conflict in
> mm/slab.c between commit fccd5095804ffc190cb2371c319cb4f5b2c0ee14
> ("kmemtrace: SLAB hooks") from the slab tree and commit
> 30532cb3c49a2a9fed94127aab26003c52398a51 ("slab: add hooks for
> kmemcheck") from the kmemcheck tree.
> 
> Simply overlapping additions of includes.

thanks Stephen! I suspect these resolutions will live in linux-next for 
the next 2 months, as that's the soonest there will be a natural merge 
between slab.git and tip/kmemcheck.

	Ingo

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

[Pekka Enberg]

Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
>> Hi all,
>>
>> Today's linux-next merge of the kmemcheck tree got a conflict in
>> mm/slab.c between commit fccd5095804ffc190cb2371c319cb4f5b2c0ee14
>> ("kmemtrace: SLAB hooks") from the slab tree and commit
>> 30532cb3c49a2a9fed94127aab26003c52398a51 ("slab: add hooks for
>> kmemcheck") from the kmemcheck tree.
>>
>> Simply overlapping additions of includes.
> 
> thanks Stephen! I suspect these resolutions will live in linux-next for 
> the next 2 months, as that's the soonest there will be a natural merge 
> between slab.git and tip/kmemcheck.

Oh, I was just asking Stephen what to do with those. If the resolutions 
can be in linux-next, I'm fine with that.

linux-next: manual merge of the kmemcheck tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the kmemcheck tree got a conflict in
mm/slab.c between commit fccd5095804ffc190cb2371c319cb4f5b2c0ee14
("kmemtrace: SLAB hooks") from the slab tree and commit
30532cb3c49a2a9fed94127aab26003c52398a51 ("slab: add hooks for
kmemcheck") from the kmemcheck tree.

Simply overlapping additions of includes.
-- 
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 kmemcheck tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the kmemcheck tree got a trivial conflict in
mm/Makefile between commit 5db80305ad7ea891246aec24204630c2925e7b12
("kmemtrace: Core implementation") from the slab tree and commit
e6df1035b1b488cafde1e69f1a25f2706c3ac1f7 ("kmemcheck: add mm functions")
from the kmemcheck tree.

The latter removed an empty line that the former replaced.
-- 
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 kmemcheck tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the kmemcheck tree got a conflict in
MAINTAINERS between commit 5db80305ad7ea891246aec24204630c2925e7b12
("kmemtrace: Core implementation") from the slab tree and commit
3994d3f08b618f9c40af1d402c3e4ecec946b5dc ("kmemcheck: add Vegard and
Pekka to MAINTAINERS") from the kmemcheck tree.

Simply overlapping additions. I added both.
-- 
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 kmemcheck tree

[Stephen Rothwell]

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

Hi Ingo,

On Mon, 28 Jul 2008 11:06:35 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> Thanks Stephen. I have done the same merge fixup yesterday in tip/master 
> and pushed it out today into tip/auto-kmemcheck-next. The conflict 
> should disappear on your next integration run.

Thanks.

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

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

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

[Ingo Molnar]

* Vegard Nossum <vegard.nossum@gmail.com> wrote:

> > thanks Stephen.
> >
> > I made this fixup too, yesterday, but solved it differently: i added 
> > kmemcheck_init() to before all early initcalls. I think that's the 
> > best solution for a fundamental debug feature like kmemcheck. (which 
> > could catch bugs in early initcalls as well) What do you think?
> >
> > i've pushed out a new auto-kmemcheck-next branch, so the conflicts 
> > should go away on your next iteration.
> 
> I'm sorry, I didn't have the chance to review your conflict 
> resolutions yet.
> 
> But I think it's correct to use an early_initcall() -- we do catch 
> errors even before kmemcheck_init(); the only purpose of 
> kmemcheck_init is to prevent additional CPUs from going up. And that's 
> exactly the purpose of "early initcalls", to run just before 
> additional CPUs are upped. (Yeah, I did point out in review that 
> "presmp_initcall" would have been a better name than "early", at least 
> for our purposes, however, it seems that the idea was rejected.)
> 
> Perhaps kmemcheck_init() is a misnomer as well. We are functional 
> before that, too. If you are looking for a different init() function, 
> there isn't one :-) Just an option parser, param_kmemcheck().

ok - could you please dig out Stephen's conflict resolution and send a 
patch against tip/kmemcheck? (or better yet, a pull request ;-)

	Ingo

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

[Vegard Nossum]

On Mon, Jul 28, 2008 at 11:05 AM, Ingo Molnar <mingo@elte.hu> wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Today's linux-next merge of the kmemcheck tree got a conflict in
>> init/main.c between commits c2147a5092cfe13dbf3210e54e8a622015edeecc
>> ("Better interface for hooking early initcalls") and
>> 7babe8db99d305340cf4828ce1f5a1481d5622ef ("Full conversion to
>> early_initcall() interface, remove old interface") from Linus' tree
>> and commit 385e31b9eae0528bada07d16a189f3f40df23961 ("kmemcheck: add
>> the kmemcheck core") from the kmemcheck tree.
>>
>> I used the upstream version and turned kmemcheck_init into an
>> early_initcall().
>
> thanks Stephen.
>
> I made this fixup too, yesterday, but solved it differently: i added
> kmemcheck_init() to before all early initcalls. I think that's the best
> solution for a fundamental debug feature like kmemcheck. (which could
> catch bugs in early initcalls as well) What do you think?
>
> i've pushed out a new auto-kmemcheck-next branch, so the conflicts
> should go away on your next iteration.

I'm sorry, I didn't have the chance to review your conflict resolutions yet.

But I think it's correct to use an early_initcall() -- we do catch
errors even before kmemcheck_init(); the only purpose of
kmemcheck_init is to prevent additional CPUs from going up. And that's
exactly the purpose of "early initcalls", to run just before
additional CPUs are upped. (Yeah, I did point out in review that
"presmp_initcall" would have been a better name than "early", at least
for our purposes, however, it seems that the idea was rejected.)

Perhaps kmemcheck_init() is a misnomer as well. We are functional
before that, too. If you are looking for a different init() function,
there isn't one :-) Just an option parser, param_kmemcheck().


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036

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

[Ingo Molnar]

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

> Hi all,
> 
> Today's linux-next merge of the kmemcheck tree got a conflict in 
> mm/slab.c between commit 51cc50685a4275c6a02653670af9f108a64e01cf 
> ("SL*B: drop kmem cache argument from constructor") from Linus' tree 
> and commit c9506812f317bca0edcbc717c8fdabdd1d0a264b ("slab: move 
> struct kmem_cache to headers") from the kmemcheck tree.
> 
> The former changed the ctor field of the structure that the latter 
> moved to a different file.  I fixed it up in its new location.

Thanks Stephen. I have done the same merge fixup yesterday in tip/master 
and pushed it out today into tip/auto-kmemcheck-next. The conflict 
should disappear on your next integration run.

	Ingo

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

[Ingo Molnar]

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

> Hi all,
> 
> Today's linux-next merge of the kmemcheck tree got a conflict in 
> init/main.c between commits c2147a5092cfe13dbf3210e54e8a622015edeecc 
> ("Better interface for hooking early initcalls") and 
> 7babe8db99d305340cf4828ce1f5a1481d5622ef ("Full conversion to 
> early_initcall() interface, remove old interface") from Linus' tree 
> and commit 385e31b9eae0528bada07d16a189f3f40df23961 ("kmemcheck: add 
> the kmemcheck core") from the kmemcheck tree.
> 
> I used the upstream version and turned kmemcheck_init into an 
> early_initcall().

thanks Stephen.

I made this fixup too, yesterday, but solved it differently: i added 
kmemcheck_init() to before all early initcalls. I think that's the best 
solution for a fundamental debug feature like kmemcheck. (which could 
catch bugs in early initcalls as well) What do you think?

i've pushed out a new auto-kmemcheck-next branch, so the conflicts 
should go away on your next iteration.

	Ingo

linux-next: manual merge of the kmemcheck tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the kmemcheck tree got a conflict in
mm/slab.c between commit 51cc50685a4275c6a02653670af9f108a64e01cf ("SL*B:
drop kmem cache argument from constructor") from Linus' tree and commit
c9506812f317bca0edcbc717c8fdabdd1d0a264b ("slab: move struct kmem_cache
to headers") from the kmemcheck tree.

The former changed the ctor field of the structure that the latter moved
to a different file.  I fixed it up in its new location.

-- 
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 kmemcheck tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the kmemcheck tree got a conflict in
init/main.c between commits c2147a5092cfe13dbf3210e54e8a622015edeecc
("Better interface for hooking early initcalls") and
7babe8db99d305340cf4828ce1f5a1481d5622ef ("Full conversion to
early_initcall() interface, remove old interface") from Linus' tree and
commit 385e31b9eae0528bada07d16a189f3f40df23961 ("kmemcheck: add the
kmemcheck core") from the kmemcheck tree.

I used the upstream version and turned kmemcheck_init into an
early_initcall().

-- 
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 kmemcheck tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the kmemcheck tree got a conflict in
kernel/sysctl.c between commit 46dd972f573f3b697c1c2de6a0ca73a2cde7d3c0
("stop_machine:add_stopmachine_timeout") from the rr tree and commit
385e31b9eae0528bada07d16a189f3f40df23961 ("kmemcheck: add the kmemcheck
core") from the kmemcheck tree.

Just overlapping additions/removal.  I can carry the fixup.
-- 
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 kmemcheck tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the kmemcheck tree got a conflict in
arch/x86/kernel/traps_64.c between commit
badc76527f7e29302f0bde3d366c59101fb2ab87 ("x86: traps_xx: shuffle headers
and globals") from the x86 tree and commit
862849a36e6087faac6349de0b1bcc66ff98411b ("x86: add hooks for kmemcheck
on x86_64") from the kmemcheck tree.

Just overlapping shuffling and adding of include files.
-- 
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 kmemcheck tree

[Ingo Molnar]

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

> Hi Ingo,
> 
> Today's linux-next merge of the kmemcheck tree got a conflict in 
> arch/x86/mm/Makefile between commit 
> ff3a3e9ba5e4273a8bc10570adab4a390fb90757 ("x86 mmiotrace: move files 
> into arch/x86/mm/") from the ftrace tree and commit 
> 385e31b9eae0528bada07d16a189f3f40df23961 ("kmemcheck: add the 
> kmemcheck core") from the kmemcheck tree.
> 
> Just overlapping additions.

thanks Stephen. These are the conflict resolutions i've been carrying 
for a few months:

    Merge branch 'kmemcheck' into auto-latest

    Conflicts:

        arch/x86/mm/Makefile
        include/asm-x86/pgtable.h
        kernel/sysctl.c

the arch/x86/mm/Makefile and kernel/sysctl.c ones are trivial - but the 
pgtable.h is non-trivial: you might want to glean the resolution out of 
tip/auto-latest.

Shortly before the release of a stable kernel is the 'maximum dynamic 
pressure' point of the launch of the next Linux version - this is when 
the highest number of conflicts arise. [ And i hope these three are not 
too bad to break the rocket apart ;-) ]

	Ingo

linux-next: manual merge of the kmemcheck tree

[Stephen Rothwell]

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

Hi Ingo,

Today's linux-next merge of the kmemcheck tree got a conflict in
include/asm-x86/pgtable.h between commit
4226ab93d8ae3fd895abe45879fe34d489a98718 ("x86: use pteval_t for
_PAGE_FOO") from the x86 tree and commit
385e31b9eae0528bada07d16a189f3f40df23961 ("kmemcheck: add the kmemcheck
core") from the kmemcheck tree.

I used the former version except I made the UNUSED3 -> HIDDEN change from
the latter.

-- 
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 kmemcheck tree

[Stephen Rothwell]

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

Hi Ingo,

Today's linux-next merge of the kmemcheck tree got a conflict in
arch/x86/mm/Makefile between commit
ff3a3e9ba5e4273a8bc10570adab4a390fb90757 ("x86 mmiotrace: move files into
arch/x86/mm/") from the ftrace tree and commit
385e31b9eae0528bada07d16a189f3f40df23961 ("kmemcheck: add the kmemcheck
core") from the kmemcheck tree.

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