* Vegard Nossum <vegard.nossum@xxxxxxxxx> wrote: > 2009/3/6 Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>: > > 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@xxxxxxxxxxxxxxxx > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html