linux-next: manual merge of the xen tree with the tip tree

linux-next: manual merge of the xen tree with the tip tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the xen tree got a conflict in
arch/x86/mm/init_32.c between commit
1d931264af0f10649b35afa8fbd2e169da51ac08 ("x86-32, memblock: Make
add_highpages honor early reserved ranges") from the tip tree and commit
07147a06ac3b1b028124ea00ba44e69eb8ea7685 ("x86/32: honor reservations of
high memory") from the xen tree.

I have no idea how to fix this up, sorry, so I have used the xen tree
from next-20101021 for today.

There were also conflicts in:
	arch/x86/xen/mmu.c
	include/linux/early_res.h
	kernel/early_res.c

These last two were deleted in the tip tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the xen tree with the tip tree

[Stephen Rothwell]

Hi Jeremy,

On Fri, 22 Oct 2010 14:03:35 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the xen tree got a conflict in
> arch/x86/mm/init_32.c between commit
> 1d931264af0f10649b35afa8fbd2e169da51ac08 ("x86-32, memblock: Make
> add_highpages honor early reserved ranges") from the tip tree and commit
> 07147a06ac3b1b028124ea00ba44e69eb8ea7685 ("x86/32: honor reservations of
> high memory") from the xen tree.
> 
> I have no idea how to fix this up, sorry, so I have used the xen tree
> from next-20101021 for today.

It occurred to me that the conflicts might be useful to you, so here they
are:

diff --cc arch/x86/mm/init_32.c
index 5d0a671,573bc7f..0000000
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@@ -423,28 -422,71 +423,78 @@@ static void __init add_one_highpage_ini
  	totalhigh_pages++;
  }
  
 -struct add_highpages_data {
 -	unsigned long start_pfn;
 -	unsigned long end_pfn;
 -};
 -
 -static int __init add_highpages_work_fn(unsigned long start_pfn,
 -					 unsigned long end_pfn, void *datax)
 +void __init add_highpages_with_active_regions(int nid,
 +			 unsigned long start_pfn, unsigned long end_pfn)
  {
++<<<<<<< HEAD
 +	struct range *range;
 +	int nr_range;
 +	int i;
 +
 +	nr_range = __get_free_all_memory_range(&range, nid, start_pfn, end_pfn);
++=======
+ 	int node_pfn;
+ 	struct page *page;
+ 	phys_addr_t chunk_end, chunk_max;
+ 	unsigned long final_start_pfn, final_end_pfn;
+ 	struct add_highpages_data *data = (struct add_highpages_data *)datax;
++>>>>>>> xen
  
 -	final_start_pfn = max(start_pfn, data->start_pfn);
 -	final_end_pfn = min(end_pfn, data->end_pfn);
 -	if (final_start_pfn >= final_end_pfn)
 -		return 0;
 +	for (i = 0; i < nr_range; i++) {
 +		struct page *page;
 +		int node_pfn;
  
++<<<<<<< HEAD
 +		for (node_pfn = range[i].start; node_pfn < range[i].end;
 +		     node_pfn++) {
++=======
+ 	chunk_end = PFN_PHYS(final_start_pfn);
+ 	chunk_max = PFN_PHYS(final_end_pfn);
+ 
+ 	/*
+ 	 * Check for reserved areas.
+ 	 */
+ 	for (;;) {
+ 		phys_addr_t chunk_start;
+ 		chunk_start = early_res_next_free(chunk_end);
+ 		
+ 		/*
+ 		 * Reserved area. Just count high mem pages.
+ 		 */
+ 		for (node_pfn = PFN_DOWN(chunk_end);
+ 		     node_pfn < PFN_DOWN(chunk_start); node_pfn++) {
+ 			if (pfn_valid(node_pfn))
+ 				totalhigh_pages++;
+ 		}
+ 
+ 		if (chunk_start >= chunk_max)
+ 			break;
+ 
+ 		chunk_end = early_res_next_reserved(chunk_start, chunk_max);
+ 		for (node_pfn = PFN_DOWN(chunk_start);
+ 		     node_pfn < PFN_DOWN(chunk_end); node_pfn++) {
++>>>>>>> xen
  			if (!pfn_valid(node_pfn))
  				continue;
  			page = pfn_to_page(node_pfn);
  			add_one_highpage_init(page);
  		}
  	}
 -
 -	return 0;
 -
  }
++<<<<<<< HEAD
++=======
+ 
+ void __init add_highpages_with_active_regions(int nid, unsigned long start_pfn,
+ 					      unsigned long end_pfn)
+ {
+ 	struct add_highpages_data data;
+ 
+ 	data.start_pfn = start_pfn;
+ 	data.end_pfn = end_pfn;
+ 	work_with_active_regions(nid, add_highpages_work_fn, &data);
+ }
+ 
++>>>>>>> xen
  #else
  static inline void permanent_kmaps_init(pgd_t *pgd_base)
  {
diff --cc arch/x86/xen/mmu.c
index f72d18c,930986d..0000000
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@@ -56,7 -55,7 +56,11 @@@
  #include <asm/e820.h>
  #include <asm/linkage.h>
  #include <asm/page.h>
++<<<<<<< HEAD
 +#include <asm/init.h>
++=======
+ #include <asm/pat.h>
++>>>>>>> xen
  
  #include <asm/xen/hypercall.h>
  #include <asm/xen/hypervisor.h>
* Unmerged path include/linux/early_res.h
* Unmerged path kernel/early_res.c

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

Re: linux-next: manual merge of the xen tree with the tip tree

[Yinghai Lu]

On 10/21/2010 08:36 PM, Stephen Rothwell wrote:
> Hi Jeremy,
> 
> On Fri, 22 Oct 2010 14:03:35 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Today's linux-next merge of the xen tree got a conflict in
>> arch/x86/mm/init_32.c between commit
>> 1d931264af0f10649b35afa8fbd2e169da51ac08 ("x86-32, memblock: Make
>> add_highpages honor early reserved ranges") from the tip tree and commit
>> 07147a06ac3b1b028124ea00ba44e69eb8ea7685 ("x86/32: honor reservations of
>> high memory") from the xen tree.
>>
>> I have no idea how to fix this up, sorry, so I have used the xen tree
>> from next-20101021 for today.
> 

x86-32, memblock: Make add_highpages honor early reserved ranges

is updated version with memblock for

x86/32: honor reservations of high memory

Assume Jeremy would update the xen tree.

Thanks

	Yinghai

Re: linux-next: manual merge of the xen tree with the tip tree

[Ingo Molnar]

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

> Hi all,
> 
> Today's linux-next merge of the xen tree got a conflict in
> arch/x86/mm/init_32.c between commit
> 1d931264af0f10649b35afa8fbd2e169da51ac08 ("x86-32, memblock: Make
> add_highpages honor early reserved ranges") from the tip tree and commit
> 07147a06ac3b1b028124ea00ba44e69eb8ea7685 ("x86/32: honor reservations of
> high memory") from the xen tree.

Jeremy,

Commit 07147a06ac is all over the x86 tree:

  arch/x86/mm/init_32.c     |   42 ++++++++++++++++++++++++++++++++----------
  include/linux/early_res.h |    3 +++
  kernel/early_res.c        |   30 ++++++++++++++++++++++++++++++
  3 files changed, 65 insertions(+), 10 deletions(-)

... but there's no x86 person who acked it or was Cc:-ed to this commit AFAICS. It 
was not even posted to lkml! Nor does the commit title suggest that it affects core 
kernel code as well.

Also, the AuthorDate field is a total lie:

  commit 07147a06ac3b1b028124ea00ba44e69eb8ea7685
  Author:     Gianluca Guida <gianluca.guida@citrix.com>
  AuthorDate: Sun Aug 2 01:25:48 2009 +0100
  Commit:     Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
  CommitDate: Mon Oct 4 14:22:11 2010 -0700

    x86/32: honor reservations of high memory

This commit was written on Aug 2 2009, really? kernel/early_res.c, which is modified 
by half of this commit, was _CREATED_ in February 2010 ...

I realize that some original patch, much different from this one, was probably 
written in 2009, and that via a series of undocumented rebases and modifications to 
the patch you achieved this state.

Crap like that is just _NOT_ acceptable, and you know that perfectly well - if you 
do this to arch/x86/ i'll be forced to ask for the Xen tree to be removed from 
linux-next and be done via the x86 tree again.

	Ingo

Re: linux-next: manual merge of the xen tree with the tip tree

[Jeremy Fitzhardinge]

 On 10/22/2010 01:01 AM, Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi all,
>>
>> Today's linux-next merge of the xen tree got a conflict in
>> arch/x86/mm/init_32.c between commit
>> 1d931264af0f10649b35afa8fbd2e169da51ac08 ("x86-32, memblock: Make
>> add_highpages honor early reserved ranges") from the tip tree and commit
>> 07147a06ac3b1b028124ea00ba44e69eb8ea7685 ("x86/32: honor reservations of
>> high memory") from the xen tree.
> Jeremy,
>
> Commit 07147a06ac is all over the x86 tree:
>
>   arch/x86/mm/init_32.c     |   42 ++++++++++++++++++++++++++++++++----------
>   include/linux/early_res.h |    3 +++
>   kernel/early_res.c        |   30 ++++++++++++++++++++++++++++++
>   3 files changed, 65 insertions(+), 10 deletions(-)
>
> ... but there's no x86 person who acked it or was Cc:-ed to this commit AFAICS. It 
> was not even posted to lkml! Nor does the commit title suggest that it affects core 
> kernel code as well.
>
> Also, the AuthorDate field is a total lie:
>
>   commit 07147a06ac3b1b028124ea00ba44e69eb8ea7685
>   Author:     Gianluca Guida <gianluca.guida@citrix.com>
>   AuthorDate: Sun Aug 2 01:25:48 2009 +0100
>   Commit:     Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>   CommitDate: Mon Oct 4 14:22:11 2010 -0700
>
>     x86/32: honor reservations of high memory
>
> This commit was written on Aug 2 2009, really? kernel/early_res.c, which is modified 
> by half of this commit, was _CREATED_ in February 2010 ...

Most of the code in early_res.c was simply moved from
arch/x86/.../e820.c, so the patch chunks were applied to the new file
when the code was moved.

> I realize that some original patch, much different from this one, was probably 
> written in 2009, and that via a series of undocumented rebases and modifications to 
> the patch you achieved this state.

The modified code was almost entirely unchanged over that period, so the
datestamp and original authorship of the patch was basically correct.

However...

> Crap like that is just _NOT_ acceptable, and you know that perfectly well - if you 
> do this to arch/x86/ i'll be forced to ask for the Xen tree to be removed from 
> linux-next and be done via the x86 tree again.

Hey, hey, hold your horses.  This is a wildly obsolete patch that we
were discussing a few weeks ago, but Yinghai did a proper alternative
for the memblock universe.

It was never in linux-next, and never intended to be.  I'm not sure why
it has appeared in linux-next now; it isn't in my branch.  I wonder if
it appeared in another Xen-related branch.  Let me investigate.

    J

Re: linux-next: manual merge of the xen tree with the tip tree

[Jeremy Fitzhardinge]

 On 10/21/2010 08:03 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the xen tree got a conflict in
> arch/x86/mm/init_32.c between commit
> 1d931264af0f10649b35afa8fbd2e169da51ac08 ("x86-32, memblock: Make
> add_highpages honor early reserved ranges") from the tip tree and commit
> 07147a06ac3b1b028124ea00ba44e69eb8ea7685 ("x86/32: honor reservations of
> high memory") from the xen tree.

Hm, that change has been completely obsoleted by the memblock stuff from
tip.  Oh, I see.  Another change which ended up reverting that patch via
a merge got dropped, so it got left lying around.  I'll pull it out.

(Not sure why it merges cleanly for me however; I guess because you've
already got the older xen branch in there which contains the merge.)

Anyway, update pushed.

    J

Re: [Xen-devel] Re: linux-next: manual merge of the xen tree with the tip tree

[Stefano Stabellini]

On Fri, 22 Oct 2010, Jeremy Fitzhardinge wrote:
> > Crap like that is just _NOT_ acceptable, and you know that perfectly well - if you 
> > do this to arch/x86/ i'll be forced to ask for the Xen tree to be removed from 
> > linux-next and be done via the x86 tree again.
> 
> Hey, hey, hold your horses.  This is a wildly obsolete patch that we
> were discussing a few weeks ago, but Yinghai did a proper alternative
> for the memblock universe.
> 
> It was never in linux-next, and never intended to be.  I'm not sure why
> it has appeared in linux-next now; it isn't in my branch.  I wonder if
> it appeared in another Xen-related branch.  Let me investigate.

I think I merged in my tree a snapshot of Jeremy's upstream/xen that
apparently was not meant for upstream at all.
And I did that just to solve a trivial 5 lines conflict because my patch
series don't actually depend on any of Jeremy's patches.

I solved the problem taking the radical approach: I removed the
merge with upstream/xen altogether and also removed the commit that
conflicts with one of Jeremy's commits.
There shouldn't be any more conflicts now, and surely there shouldn't be
any more unwanted old commits.

I apologize for any problems caused but none of this was intentional.