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

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

 



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?


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