From: Ard Biesheuvel <[email protected]>
free_highpages() iterates over the free memblock regions in high
memory, and marks each page as available for the memory management
system.
Until commit cddb5ddf2b76 ("arm, xtensa: simplify initialization of
high memory pages") it rounded beginning of each region upwards and end of
each region downwards.
However, after that commit free_highmem() rounds the beginning and end of
each region downwards, and we may end up freeing a page that is
memblock_reserve()d, resulting in memory corruption.
Restore the original rounding of the region boundaries to avoid freeing
reserved pages.
Fixes: cddb5ddf2b76 ("arm, xtensa: simplify initialization of high memory pages")
Link: https://lore.kernel.org/r/[email protected]/
Signed-off-by: Ard Biesheuvel <[email protected]>
Co-developed-by: Mike Rapoport <[email protected]>
Signed-off-by: Mike Rapoport <[email protected]>
---
Max, Russell,
Please let me know how do you prefer to take it upstream.
If needed this can go via memblock tree.
v2: fix words order in the commit message
arch/arm/mm/init.c | 4 ++--
arch/xtensa/mm/init.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index d57112a276f5..c23dbf8bebee 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -354,8 +354,8 @@ static void __init free_highpages(void)
/* set highmem page free */
for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE,
&range_start, &range_end, NULL) {
- unsigned long start = PHYS_PFN(range_start);
- unsigned long end = PHYS_PFN(range_end);
+ unsigned long start = PFN_UP(range_start);
+ unsigned long end = PFN_DOWN(range_end);
/* Ignore complete lowmem entries */
if (end <= max_low)
diff --git a/arch/xtensa/mm/init.c b/arch/xtensa/mm/init.c
index c6fc83efee0c..8731b7ad9308 100644
--- a/arch/xtensa/mm/init.c
+++ b/arch/xtensa/mm/init.c
@@ -89,8 +89,8 @@ static void __init free_highpages(void)
/* set highmem page free */
for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE,
&range_start, &range_end, NULL) {
- unsigned long start = PHYS_PFN(range_start);
- unsigned long end = PHYS_PFN(range_end);
+ unsigned long start = PFN_UP(range_start);
+ unsigned long end = PFN_DOWN(range_end);
/* Ignore complete lowmem entries */
if (end <= max_low)
--
2.28.0
On Sat, Oct 31, 2020 at 11:43:45AM +0200, Mike Rapoport wrote:
> From: Ard Biesheuvel <[email protected]>
>
> free_highpages() iterates over the free memblock regions in high
> memory, and marks each page as available for the memory management
> system.
>
> Until commit cddb5ddf2b76 ("arm, xtensa: simplify initialization of
> high memory pages") it rounded beginning of each region upwards and end of
> each region downwards.
>
> However, after that commit free_highmem() rounds the beginning and end of
> each region downwards, and we may end up freeing a page that is
> memblock_reserve()d, resulting in memory corruption.
>
> Restore the original rounding of the region boundaries to avoid freeing
> reserved pages.
>
> Fixes: cddb5ddf2b76 ("arm, xtensa: simplify initialization of high memory pages")
> Link: https://lore.kernel.org/r/[email protected]/
> Signed-off-by: Ard Biesheuvel <[email protected]>
> Co-developed-by: Mike Rapoport <[email protected]>
> Signed-off-by: Mike Rapoport <[email protected]>
> ---
>
> Max, Russell,
>
> Please let me know how do you prefer to take it upstream.
> If needed this can go via memblock tree.
>
> v2: fix words order in the commit message
I really don't understand what is going on here; there seems to be a
total disconnect of communication between yourself and Ard. Ard has
already submitted a different patch for this to the patch system
already, sent yesterday.
https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9021/1
Please discuss between yourselves how you want to solve the problem,
and then submit an agreed and tested patch to those of us upstream;
please don't make it for those upstream to pick one of your patches
as you are at present.
Thanks.
>
> arch/arm/mm/init.c | 4 ++--
> arch/xtensa/mm/init.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index d57112a276f5..c23dbf8bebee 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -354,8 +354,8 @@ static void __init free_highpages(void)
> /* set highmem page free */
> for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE,
> &range_start, &range_end, NULL) {
> - unsigned long start = PHYS_PFN(range_start);
> - unsigned long end = PHYS_PFN(range_end);
> + unsigned long start = PFN_UP(range_start);
> + unsigned long end = PFN_DOWN(range_end);
>
> /* Ignore complete lowmem entries */
> if (end <= max_low)
> diff --git a/arch/xtensa/mm/init.c b/arch/xtensa/mm/init.c
> index c6fc83efee0c..8731b7ad9308 100644
> --- a/arch/xtensa/mm/init.c
> +++ b/arch/xtensa/mm/init.c
> @@ -89,8 +89,8 @@ static void __init free_highpages(void)
> /* set highmem page free */
> for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE,
> &range_start, &range_end, NULL) {
> - unsigned long start = PHYS_PFN(range_start);
> - unsigned long end = PHYS_PFN(range_end);
> + unsigned long start = PFN_UP(range_start);
> + unsigned long end = PFN_DOWN(range_end);
>
> /* Ignore complete lowmem entries */
> if (end <= max_low)
> --
> 2.28.0
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Sat, 31 Oct 2020 at 11:33, Russell King - ARM Linux admin
<[email protected]> wrote:
>
> On Sat, Oct 31, 2020 at 11:43:45AM +0200, Mike Rapoport wrote:
> > From: Ard Biesheuvel <[email protected]>
> >
> > free_highpages() iterates over the free memblock regions in high
> > memory, and marks each page as available for the memory management
> > system.
> >
> > Until commit cddb5ddf2b76 ("arm, xtensa: simplify initialization of
> > high memory pages") it rounded beginning of each region upwards and end of
> > each region downwards.
> >
> > However, after that commit free_highmem() rounds the beginning and end of
> > each region downwards, and we may end up freeing a page that is
> > memblock_reserve()d, resulting in memory corruption.
> >
> > Restore the original rounding of the region boundaries to avoid freeing
> > reserved pages.
> >
> > Fixes: cddb5ddf2b76 ("arm, xtensa: simplify initialization of high memory pages")
> > Link: https://lore.kernel.org/r/[email protected]/
> > Signed-off-by: Ard Biesheuvel <[email protected]>
> > Co-developed-by: Mike Rapoport <[email protected]>
> > Signed-off-by: Mike Rapoport <[email protected]>
> > ---
> >
> > Max, Russell,
> >
> > Please let me know how do you prefer to take it upstream.
> > If needed this can go via memblock tree.
> >
> > v2: fix words order in the commit message
>
> I really don't understand what is going on here; there seems to be a
> total disconnect of communication between yourself and Ard. Ard has
> already submitted a different patch for this to the patch system
> already, sent yesterday.
>
> https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9021/1
>
> Please discuss between yourselves how you want to solve the problem,
> and then submit an agreed and tested patch to those of us upstream;
> please don't make it for those upstream to pick one of your patches
> as you are at present.
>
Apologies for creating this confusion. I posted a patch and dropped it
into the patch system when I found the bug.
However, only when Florian asked about a 'fixes' tag, I went back to
the history, and realized that the issue was introduced by Mike during
the most recent merge window, and affects xtensa as well.
I don't have a preference which patch gets applied, though, so please
indicate your preference, and we will adapt accordingly.
> >
> > arch/arm/mm/init.c | 4 ++--
> > arch/xtensa/mm/init.c | 4 ++--
> > 2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> > index d57112a276f5..c23dbf8bebee 100644
> > --- a/arch/arm/mm/init.c
> > +++ b/arch/arm/mm/init.c
> > @@ -354,8 +354,8 @@ static void __init free_highpages(void)
> > /* set highmem page free */
> > for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE,
> > &range_start, &range_end, NULL) {
> > - unsigned long start = PHYS_PFN(range_start);
> > - unsigned long end = PHYS_PFN(range_end);
> > + unsigned long start = PFN_UP(range_start);
> > + unsigned long end = PFN_DOWN(range_end);
> >
> > /* Ignore complete lowmem entries */
> > if (end <= max_low)
> > diff --git a/arch/xtensa/mm/init.c b/arch/xtensa/mm/init.c
> > index c6fc83efee0c..8731b7ad9308 100644
> > --- a/arch/xtensa/mm/init.c
> > +++ b/arch/xtensa/mm/init.c
> > @@ -89,8 +89,8 @@ static void __init free_highpages(void)
> > /* set highmem page free */
> > for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE,
> > &range_start, &range_end, NULL) {
> > - unsigned long start = PHYS_PFN(range_start);
> > - unsigned long end = PHYS_PFN(range_end);
> > + unsigned long start = PFN_UP(range_start);
> > + unsigned long end = PFN_DOWN(range_end);
> >
> > /* Ignore complete lowmem entries */
> > if (end <= max_low)
> > --
> > 2.28.0
> >
> >
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Sat, Oct 31, 2020 at 11:47:42AM +0100, Ard Biesheuvel wrote:
> On Sat, 31 Oct 2020 at 11:33, Russell King - ARM Linux admin
> <[email protected]> wrote:
> >
> > On Sat, Oct 31, 2020 at 11:43:45AM +0200, Mike Rapoport wrote:
> > > From: Ard Biesheuvel <[email protected]>
> > >
> > > free_highpages() iterates over the free memblock regions in high
> > > memory, and marks each page as available for the memory management
> > > system.
> > >
> > > Until commit cddb5ddf2b76 ("arm, xtensa: simplify initialization of
> > > high memory pages") it rounded beginning of each region upwards and end of
> > > each region downwards.
> > >
> > > However, after that commit free_highmem() rounds the beginning and end of
> > > each region downwards, and we may end up freeing a page that is
> > > memblock_reserve()d, resulting in memory corruption.
> > >
> > > Restore the original rounding of the region boundaries to avoid freeing
> > > reserved pages.
> > >
> > > Fixes: cddb5ddf2b76 ("arm, xtensa: simplify initialization of high memory pages")
> > > Link: https://lore.kernel.org/r/[email protected]/
> > > Signed-off-by: Ard Biesheuvel <[email protected]>
> > > Co-developed-by: Mike Rapoport <[email protected]>
> > > Signed-off-by: Mike Rapoport <[email protected]>
> > > ---
> > >
> > > Max, Russell,
> > >
> > > Please let me know how do you prefer to take it upstream.
> > > If needed this can go via memblock tree.
> > >
> > > v2: fix words order in the commit message
> >
> > I really don't understand what is going on here; there seems to be a
> > total disconnect of communication between yourself and Ard. Ard has
> > already submitted a different patch for this to the patch system
> > already, sent yesterday.
> >
> > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9021/1
> >
> > Please discuss between yourselves how you want to solve the problem,
> > and then submit an agreed and tested patch to those of us upstream;
> > please don't make it for those upstream to pick one of your patches
> > as you are at present.
> >
>
> Apologies for creating this confusion. I posted a patch and dropped it
> into the patch system when I found the bug.
>
> However, only when Florian asked about a 'fixes' tag, I went back to
> the history, and realized that the issue was introduced by Mike during
> the most recent merge window, and affects xtensa as well.
So why does Mike's patch have:
Signed-off-by: Ard Biesheuvel <[email protected]>
in it? It seems you haven't been directly involved in Mike's patch.
There's something /really/ not right with the process behind this
patch.
> I don't have a preference which patch gets applied, though, so please
> indicate your preference, and we will adapt accordingly.
I asked for you both to come to a concensus about how you want to
proceed, and now you're throwing it back on to me to solve your(pl)
mis-communication issue. We haven't heard from Mike yet.
Clearly, I wasn't blunt and stroppy enough to be properly understood.
Sort it out between yourselves and tell me which patch you want me to
apply.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Sat, 31 Oct 2020 at 12:04, Russell King - ARM Linux admin
<[email protected]> wrote:
>
> On Sat, Oct 31, 2020 at 11:47:42AM +0100, Ard Biesheuvel wrote:
> > On Sat, 31 Oct 2020 at 11:33, Russell King - ARM Linux admin
> > <[email protected]> wrote:
> > >
> > > On Sat, Oct 31, 2020 at 11:43:45AM +0200, Mike Rapoport wrote:
> > > > From: Ard Biesheuvel <[email protected]>
> > > >
> > > > free_highpages() iterates over the free memblock regions in high
> > > > memory, and marks each page as available for the memory management
> > > > system.
> > > >
> > > > Until commit cddb5ddf2b76 ("arm, xtensa: simplify initialization of
> > > > high memory pages") it rounded beginning of each region upwards and end of
> > > > each region downwards.
> > > >
> > > > However, after that commit free_highmem() rounds the beginning and end of
> > > > each region downwards, and we may end up freeing a page that is
> > > > memblock_reserve()d, resulting in memory corruption.
> > > >
> > > > Restore the original rounding of the region boundaries to avoid freeing
> > > > reserved pages.
> > > >
> > > > Fixes: cddb5ddf2b76 ("arm, xtensa: simplify initialization of high memory pages")
> > > > Link: https://lore.kernel.org/r/[email protected]/
> > > > Signed-off-by: Ard Biesheuvel <[email protected]>
> > > > Co-developed-by: Mike Rapoport <[email protected]>
> > > > Signed-off-by: Mike Rapoport <[email protected]>
> > > > ---
> > > >
> > > > Max, Russell,
> > > >
> > > > Please let me know how do you prefer to take it upstream.
> > > > If needed this can go via memblock tree.
> > > >
> > > > v2: fix words order in the commit message
> > >
> > > I really don't understand what is going on here; there seems to be a
> > > total disconnect of communication between yourself and Ard. Ard has
> > > already submitted a different patch for this to the patch system
> > > already, sent yesterday.
> > >
> > > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9021/1
> > >
> > > Please discuss between yourselves how you want to solve the problem,
> > > and then submit an agreed and tested patch to those of us upstream;
> > > please don't make it for those upstream to pick one of your patches
> > > as you are at present.
> > >
> >
> > Apologies for creating this confusion. I posted a patch and dropped it
> > into the patch system when I found the bug.
> >
> > However, only when Florian asked about a 'fixes' tag, I went back to
> > the history, and realized that the issue was introduced by Mike during
> > the most recent merge window, and affects xtensa as well.
>
> So why does Mike's patch have:
>
> Signed-off-by: Ard Biesheuvel <[email protected]>
>
> in it? It seems you haven't been directly involved in Mike's patch.
>
Because I cc'ed him on the discussion following the patch that is now
in your patch system. So he took that patch and modified it, but
retained the original S-o-b and authorship.
> There's something /really/ not right with the process behind this
> patch.
>
> > I don't have a preference which patch gets applied, though, so please
> > indicate your preference, and we will adapt accordingly.
>
> I asked for you both to come to a concensus about how you want to
> proceed, and now you're throwing it back on to me to solve your(pl)
> mis-communication issue. We haven't heard from Mike yet.
>
I am not throwing it back to you. I merely indicated that I have no
preference, and since Mike is the one who introduced this issue in the
first place, I am expecting him to drive this. And indeed, we haven't
heard from him yet.
> Clearly, I wasn't blunt and stroppy enough to be properly understood.
> Sort it out between yourselves and tell me which patch you want me to
> apply.
>
I would like you to ack this version of the patch, and disregard the
one in the patch system, so that Mike can take this one through the
memblock tree where the issue originated in the first place.
On Sat, Oct 31, 2020 at 12:21:24PM +0100, Ard Biesheuvel wrote:
> On Sat, 31 Oct 2020 at 12:04, Russell King - ARM Linux admin
> <[email protected]> wrote:
> >
> > On Sat, Oct 31, 2020 at 11:47:42AM +0100, Ard Biesheuvel wrote:
> > > On Sat, 31 Oct 2020 at 11:33, Russell King - ARM Linux admin
> > > <[email protected]> wrote:
> > > >
> > > > On Sat, Oct 31, 2020 at 11:43:45AM +0200, Mike Rapoport wrote:
> > > > > From: Ard Biesheuvel <[email protected]>
> > > > >
> > > > > free_highpages() iterates over the free memblock regions in high
> > > > > memory, and marks each page as available for the memory management
> > > > > system.
> > > > >
> > > > > Until commit cddb5ddf2b76 ("arm, xtensa: simplify initialization of
> > > > > high memory pages") it rounded beginning of each region upwards and end of
> > > > > each region downwards.
> > > > >
> > > > > However, after that commit free_highmem() rounds the beginning and end of
> > > > > each region downwards, and we may end up freeing a page that is
> > > > > memblock_reserve()d, resulting in memory corruption.
> > > > >
> > > > > Restore the original rounding of the region boundaries to avoid freeing
> > > > > reserved pages.
> > > > >
> > > > > Fixes: cddb5ddf2b76 ("arm, xtensa: simplify initialization of high memory pages")
> > > > > Link: https://lore.kernel.org/r/[email protected]/
> > > > > Signed-off-by: Ard Biesheuvel <[email protected]>
> > > > > Co-developed-by: Mike Rapoport <[email protected]>
> > > > > Signed-off-by: Mike Rapoport <[email protected]>
> > > > > ---
> > > > >
> > > > > Max, Russell,
> > > > >
> > > > > Please let me know how do you prefer to take it upstream.
> > > > > If needed this can go via memblock tree.
> > > > >
> > > > > v2: fix words order in the commit message
> > > >
> > > > I really don't understand what is going on here; there seems to be a
> > > > total disconnect of communication between yourself and Ard. Ard has
> > > > already submitted a different patch for this to the patch system
> > > > already, sent yesterday.
> > > >
> > > > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9021/1
> > > >
> > > > Please discuss between yourselves how you want to solve the problem,
> > > > and then submit an agreed and tested patch to those of us upstream;
> > > > please don't make it for those upstream to pick one of your patches
> > > > as you are at present.
> > > >
> > >
> > > Apologies for creating this confusion. I posted a patch and dropped it
> > > into the patch system when I found the bug.
> > >
> > > However, only when Florian asked about a 'fixes' tag, I went back to
> > > the history, and realized that the issue was introduced by Mike during
> > > the most recent merge window, and affects xtensa as well.
> >
> > So why does Mike's patch have:
> >
> > Signed-off-by: Ard Biesheuvel <[email protected]>
> >
> > in it? It seems you haven't been directly involved in Mike's patch.
> >
>
> Because I cc'ed him on the discussion following the patch that is now
> in your patch system. So he took that patch and modified it, but
> retained the original S-o-b and authorship.
Right, that's exactly what happened.
> > There's something /really/ not right with the process behind this
> > patch.
> >
> > > I don't have a preference which patch gets applied, though, so please
> > > indicate your preference, and we will adapt accordingly.
> >
> > I asked for you both to come to a concensus about how you want to
> > proceed, and now you're throwing it back on to me to solve your(pl)
> > mis-communication issue. We haven't heard from Mike yet.
> >
>
> I am not throwing it back to you. I merely indicated that I have no
> preference, and since Mike is the one who introduced this issue in the
> first place, I am expecting him to drive this. And indeed, we haven't
> heard from him yet.
I didn't know that Ard's patch was already in the patch system. I took
the patch from the list, updated it, added a fix for xtensa and resend
while retaining Ard's authourship and s-o-b.
> > Clearly, I wasn't blunt and stroppy enough to be properly understood.
> > Sort it out between yourselves and tell me which patch you want me to
> > apply.
> >
>
> I would like you to ack this version of the patch, and disregard the
> one in the patch system, so that Mike can take this one through the
> memblock tree where the issue originated in the first place.
Agree.
--
Sincerely yours,
Mike.
On Sat, Oct 31, 2020 at 2:43 AM Mike Rapoport <[email protected]> wrote:
> Please let me know how do you prefer to take it upstream.
> If needed this can go via memblock tree.
Going through the memblock tree sounds right to me.
--
Thanks.
-- Max
On Sat, Oct 31, 2020 at 09:37:09AM -0700, Max Filippov wrote:
> On Sat, Oct 31, 2020 at 2:43 AM Mike Rapoport <[email protected]> wrote:
> > Please let me know how do you prefer to take it upstream.
> > If needed this can go via memblock tree.
>
> Going through the memblock tree sounds right to me.
Can I treat this as Ack?
> --
> Thanks.
> -- Max
--
Sincerely yours,
Mike.
On Sat, Oct 31, 2020 at 10:16 AM Mike Rapoport <[email protected]> wrote:
>
> On Sat, Oct 31, 2020 at 09:37:09AM -0700, Max Filippov wrote:
> > On Sat, Oct 31, 2020 at 2:43 AM Mike Rapoport <[email protected]> wrote:
> > > Please let me know how do you prefer to take it upstream.
> > > If needed this can go via memblock tree.
> >
> > Going through the memblock tree sounds right to me.
>
> Can I treat this as Ack?
Sure, for the xtensa part:
Acked-by: Max Filippov <[email protected]>
--
Thanks.
-- Max
On Sat, 31 Oct 2020 at 18:44, Max Filippov <[email protected]> wrote:
>
> On Sat, Oct 31, 2020 at 10:16 AM Mike Rapoport <[email protected]> wrote:
> >
> > On Sat, Oct 31, 2020 at 09:37:09AM -0700, Max Filippov wrote:
> > > On Sat, Oct 31, 2020 at 2:43 AM Mike Rapoport <[email protected]> wrote:
> > > > Please let me know how do you prefer to take it upstream.
> > > > If needed this can go via memblock tree.
> > >
> > > Going through the memblock tree sounds right to me.
> >
> > Can I treat this as Ack?
>
> Sure, for the xtensa part:
> Acked-by: Max Filippov <[email protected]>
>
Could we get this queued up please?
On Wed, Nov 04, 2020 at 09:35:14AM +0100, Ard Biesheuvel wrote:
> On Sat, 31 Oct 2020 at 18:44, Max Filippov <[email protected]> wrote:
> >
> > On Sat, Oct 31, 2020 at 10:16 AM Mike Rapoport <[email protected]> wrote:
> > >
> > > On Sat, Oct 31, 2020 at 09:37:09AM -0700, Max Filippov wrote:
> > > > On Sat, Oct 31, 2020 at 2:43 AM Mike Rapoport <[email protected]> wrote:
> > > > > Please let me know how do you prefer to take it upstream.
> > > > > If needed this can go via memblock tree.
> > > >
> > > > Going through the memblock tree sounds right to me.
> > >
> > > Can I treat this as Ack?
> >
> > Sure, for the xtensa part:
> > Acked-by: Max Filippov <[email protected]>
> >
>
> Could we get this queued up please?
It's in memblock/fixes now, I'd like to have it in next for day or two.
--
Sincerely yours,
Mike.
Hi Russell,
On Sat, Oct 31, 2020 at 05:45:35PM +0200, Mike Rapoport wrote:
> On Sat, Oct 31, 2020 at 12:21:24PM +0100, Ard Biesheuvel wrote:
> > On Sat, 31 Oct 2020 at 12:04, Russell King - ARM Linux admin
> > <[email protected]> wrote:
> > >
> > > Clearly, I wasn't blunt and stroppy enough to be properly understood.
> > > Sort it out between yourselves and tell me which patch you want me to
> > > apply.
> > >
> >
> > I would like you to ack this version of the patch, and disregard the
> > one in the patch system, so that Mike can take this one through the
> > memblock tree where the issue originated in the first place.
Can I please have your ack and move forward with pushing this via
memblock tree?
--
Sincerely yours,
Mike.