Stephen Rothwell
2010-Oct-22 03:03 UTC
[Xen-devel] linux-next: manual merge of the xen tree with the tip tree
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/
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Stephen Rothwell
2010-Oct-22 03:36 UTC
[Xen-devel] Re: linux-next: manual merge of the xen tree with the tip tree
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/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yinghai Lu
2010-Oct-22 04:03 UTC
[Xen-devel] Re: linux-next: manual merge of the xen tree with the tip tree
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ingo Molnar
2010-Oct-22 08:01 UTC
[Xen-devel] Re: linux-next: manual merge of the xen tree with the tip tree
* 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2010-Oct-22 18:39 UTC
[Xen-devel] Re: linux-next: manual merge of the xen tree with the tip tree
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2010-Oct-22 19:10 UTC
[Xen-devel] Re: linux-next: manual merge of the xen tree with the tip tree
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefano Stabellini
2010-Oct-22 21:32 UTC
Re: [Xen-devel] Re: linux-next: manual merge of the xen tree with the tip tree
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel