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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Vegard Nossum <vegard.nossum@xxxxxxxxx> wrote:

> On Tue, Oct 21, 2008 at 9:32 AM, Ingo Molnar <mingo@xxxxxxx> wrote:
> >
> > * Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> 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
--
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

[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux