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

[Ingo Molnar <mingo@elte.hu>]

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

> 2009/3/6 Stephen Rothwell <sfr@canb.auug.org.au>:
> > Hi all,
> >
> > Today's linux-next merge of the kmemcheck tree got a conflict in
> > kernel/trace/ring_buffer.c between commit
> > a81bd80a0b0a405dc0483e2c428332d69da2c79f ("ring-buffer: use generic
> > version of in_nmi") from the tracing tree and commit
> > 9b7ff384ee76ced9638ab236db588a6f13916336 ("trace: annotate bitfields in
> > struct ring_buffer_event") from the kmemcheck tree.
> >
> > Just simple overlapping additions.  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 kernel/trace/ring_buffer.c
> > index f747364,b1f2f60..0000000
> > --- a/kernel/trace/ring_buffer.c
> > +++ b/kernel/trace/ring_buffer.c
> > @@@ -9,7 -7,7 +9,8 @@@
> >  #include <linux/spinlock.h>
> >  #include <linux/debugfs.h>
> >  #include <linux/uaccess.h>
> >  +#include <linux/hardirq.h>
> > + #include <linux/kmemcheck.h>
> >  #include <linux/module.h>
> >  #include <linux/percpu.h>
> >  #include <linux/mutex.h>
> >
> 
> Isn't it amazing how we both managed to put our new include in 
> exactly the same spot? :-D

Yeah - i tend to shuffle patches and order include file sections 
of headers to reduce it - but most of the time it doesnt matter 
as fixing such a conflict is about 2 seconds.

> Anyway, thanks for fixing these up, it looks good to me!

I suspect it's the same resolution like what i did in tip:master 
a few days ago or so? I dont send out notifications about 
trivial conflicts, only about non-trivial conflicts that i'm 
unsure about. That's rare - when i see a non-trivial conflict i 
work on eliminating it.

	Ingo