x86: e820 regression

x86: e820 regression

[Erick Cafferata]

The following commit introduced a regression on my system.

124049decbb121ec32742c94fb5d9d6bed8f24d8
x86/e820: put !E820_TYPE_RAM regions into memblock.reserved

and it was backported to stable, stopping the kernel to boot on my system since around 4.17.4.
It was reverted on upstream a couple months ago.
commit 2a5bda5a624d6471d25e953b9adba5182ab1b51f upstream

There are some other modifications to the file after that. However, at the very least, can
the revert be backported?

I think the original patch tries to fix a previous bug, so probably the latest commits fixed that
one correctly and need to be backported as well.

Re: x86: e820 regression

[Naoya Horiguchi]

Hi Erick,

On Mon, Dec 10, 2018 at 03:28:37AM -0500, Erick Cafferata wrote:
> The following commit introduced a regression on my system.
> 
> 124049decbb121ec32742c94fb5d9d6bed8f24d8
> x86/e820: put !E820_TYPE_RAM regions into memblock.reserved
> 
> and it was backported to stable, stopping the kernel to boot on my system since around 4.17.4.
> It was reverted on upstream a couple months ago.
> commit 2a5bda5a624d6471d25e953b9adba5182ab1b51f upstream

This commit seems not a correct pointer.
In mainline, commit 124049decbb was reverted by

    commit 9fd61bc95130d4971568b89c9548b5e0a4e18e0e
    Author: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
    Date:   Fri Oct 26 15:10:24 2018 -0700
    
        Revert "x86/e820: put !E820_TYPE_RAM regions into memblock.reserved"

and, the original problem was finally fixed by

    commit 907ec5fca3dc38d37737de826f06f25b063aa08e
    Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Date:   Fri Oct 26 15:10:15 2018 -0700
    
        mm: zero remaining unavailable struct pages
        
        Patch series "mm: Fix for movable_node boot option", v3.

so I think both patches should be backported onto v4.17.z.

Thanks,
Naoya Horiguchi

> 
> There are some other modifications to the file after that. However, at the very least, can
> the revert be backported?
> 
> I think the original patch tries to fix a previous bug, so probably the latest commits fixed that
> one correctly and need to be backported as well.
> 

Re: x86: e820 regression

[Greg KH]

On Mon, Dec 10, 2018 at 08:54:21AM +0000, Naoya Horiguchi wrote:
> Hi Erick,
> 
> On Mon, Dec 10, 2018 at 03:28:37AM -0500, Erick Cafferata wrote:
> > The following commit introduced a regression on my system.
> > 
> > 124049decbb121ec32742c94fb5d9d6bed8f24d8
> > x86/e820: put !E820_TYPE_RAM regions into memblock.reserved
> > 
> > and it was backported to stable, stopping the kernel to boot on my system since around 4.17.4.
> > It was reverted on upstream a couple months ago.
> > commit 2a5bda5a624d6471d25e953b9adba5182ab1b51f upstream
> 
> This commit seems not a correct pointer.
> In mainline, commit 124049decbb was reverted by
> 
>     commit 9fd61bc95130d4971568b89c9548b5e0a4e18e0e
>     Author: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
>     Date:   Fri Oct 26 15:10:24 2018 -0700
>     
>         Revert "x86/e820: put !E820_TYPE_RAM regions into memblock.reserved"
> 
> and, the original problem was finally fixed by
> 
>     commit 907ec5fca3dc38d37737de826f06f25b063aa08e
>     Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>     Date:   Fri Oct 26 15:10:15 2018 -0700
>     
>         mm: zero remaining unavailable struct pages
>         
>         Patch series "mm: Fix for movable_node boot option", v3.
> 
> so I think both patches should be backported onto v4.17.z.

4.17.y and 4.18.y are long end-of-life, there's nothing I can do there.

I can apply the above patches to the 4.19.y tree, is that sufficient?

thanks,

greg k-h

Re: x86: e820 regression

[Naoya Horiguchi]

On Mon, Dec 10, 2018 at 10:49:09AM +0100, Greg KH wrote:
> On Mon, Dec 10, 2018 at 08:54:21AM +0000, Naoya Horiguchi wrote:
...
> > 
> > so I think both patches should be backported onto v4.17.z.
> 
> 4.17.y and 4.18.y are long end-of-life, there's nothing I can do there.

Ah, OK. I see.

> 
> I can apply the above patches to the 4.19.y tree, is that sufficient?

I think so.
Erick, I recommend you to move to 4.19.y or later.

- Naoya

Re: x86: e820 regression

[Erick Cafferata]

If it were possible to backport it to 4.14 as well. It would be better,
but 4.19 is already good.
Also, would you port only the revert commit, or also the correct fix for
the previous issue?

Re: x86: e820 regression

[Greg KH]

On Mon, Dec 10, 2018 at 08:39:35AM -0500, Erick Cafferata wrote:
> If it were possible to backport it to 4.14 as well. It would be better,
> but 4.19 is already good.
> Also, would you port only the revert commit, or also the correct fix for
> the previous issue?

I have no context here at all, sorry.

Please properly quote your email to give us a chance.  Remember, some of
us get over a thousand emails a day...

thanks,

greg k-h

Re: x86: e820 regression

[Erick Cafferata]

On 12/10 10:49, Greg KH wrote:
> On Mon, Dec 10, 2018 at 08:54:21AM +0000, Naoya Horiguchi wrote:
> > Hi Erick,
> > 
> > On Mon, Dec 10, 2018 at 03:28:37AM -0500, Erick Cafferata wrote:
> > > The following commit introduced a regression on my system.
> > > 
> > > 124049decbb121ec32742c94fb5d9d6bed8f24d8
> > > x86/e820: put !E820_TYPE_RAM regions into memblock.reserved
> > > 
> > > and it was backported to stable, stopping the kernel to boot on my system since around 4.17.4.
> > > It was reverted on upstream a couple months ago.
> > > commit 2a5bda5a624d6471d25e953b9adba5182ab1b51f upstream
> > 
> > This commit seems not a correct pointer.
> > In mainline, commit 124049decbb was reverted by
> > 
> >     commit 9fd61bc95130d4971568b89c9548b5e0a4e18e0e
> >     Author: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
> >     Date:   Fri Oct 26 15:10:24 2018 -0700
> >     
> >         Revert "x86/e820: put !E820_TYPE_RAM regions into memblock.reserved"
> > 
> > and, the original problem was finally fixed by
> > 
> >     commit 907ec5fca3dc38d37737de826f06f25b063aa08e
> >     Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> >     Date:   Fri Oct 26 15:10:15 2018 -0700
> >     
> >         mm: zero remaining unavailable struct pages
> >         
> >         Patch series "mm: Fix for movable_node boot option", v3.
> > 
> > so I think both patches should be backported onto v4.17.z.
> 
> 4.17.y and 4.18.y are long end-of-life, there's nothing I can do there.
> 
> I can apply the above patches to the 4.19.y tree, is that sufficient?
> 
> thanks,
> 
> greg k-h
If it were possible to backport it to 4.14 as well. It would be better, 
but 4.19 is already good.
Also, would you port only the revert commit, or also the correct fix for
the previous issue?

PD: also, as it was pointed out previously, the correct commit is
9fd61bc95130d4971568b89c9548b5e0a4e18e0e.
PD2: sorry about removing the context in the previous mail.

Re: x86: e820 regression

[Sasha Levin]

On Mon, Dec 10, 2018 at 09:21:52AM -0500, Erick Cafferata wrote:
>On 12/10 10:49, Greg KH wrote:
>> On Mon, Dec 10, 2018 at 08:54:21AM +0000, Naoya Horiguchi wrote:
>> > Hi Erick,
>> >
>> > On Mon, Dec 10, 2018 at 03:28:37AM -0500, Erick Cafferata wrote:
>> > > The following commit introduced a regression on my system.
>> > >
>> > > 124049decbb121ec32742c94fb5d9d6bed8f24d8
>> > > x86/e820: put !E820_TYPE_RAM regions into memblock.reserved
>> > >
>> > > and it was backported to stable, stopping the kernel to boot on my system since around 4.17.4.
>> > > It was reverted on upstream a couple months ago.
>> > > commit 2a5bda5a624d6471d25e953b9adba5182ab1b51f upstream
>> >
>> > This commit seems not a correct pointer.
>> > In mainline, commit 124049decbb was reverted by
>> >
>> >     commit 9fd61bc95130d4971568b89c9548b5e0a4e18e0e
>> >     Author: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
>> >     Date:   Fri Oct 26 15:10:24 2018 -0700
>> >
>> >         Revert "x86/e820: put !E820_TYPE_RAM regions into memblock.reserved"
>> >
>> > and, the original problem was finally fixed by
>> >
>> >     commit 907ec5fca3dc38d37737de826f06f25b063aa08e
>> >     Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>> >     Date:   Fri Oct 26 15:10:15 2018 -0700
>> >
>> >         mm: zero remaining unavailable struct pages
>> >
>> >         Patch series "mm: Fix for movable_node boot option", v3.
>> >
>> > so I think both patches should be backported onto v4.17.z.
>>
>> 4.17.y and 4.18.y are long end-of-life, there's nothing I can do there.
>>
>> I can apply the above patches to the 4.19.y tree, is that sufficient?
>>
>> thanks,
>>
>> greg k-h
>If it were possible to backport it to 4.14 as well. It would be better,
>but 4.19 is already good.
>Also, would you port only the revert commit, or also the correct fix for
>the previous issue?
>
>PD: also, as it was pointed out previously, the correct commit is
>9fd61bc95130d4971568b89c9548b5e0a4e18e0e.
>PD2: sorry about removing the context in the previous mail.

9fd61bc95130d4971568b89c9548b5e0a4e18e0e looks like the commit that
reverts the patch in question, not an additional fix.

--
Thanks,
Sasha

Re: x86: e820 regression

[Erick Cafferata]

On 12/10 11:58, Sasha Levin wrote:
> On Mon, Dec 10, 2018 at 09:21:52AM -0500, Erick Cafferata wrote:
> > On 12/10 10:49, Greg KH wrote:
> > > On Mon, Dec 10, 2018 at 08:54:21AM +0000, Naoya Horiguchi wrote:
> > > > Hi Erick,
> > > >
> > > > On Mon, Dec 10, 2018 at 03:28:37AM -0500, Erick Cafferata wrote:
> > > > > The following commit introduced a regression on my system.
> > > > >
> > > > > 124049decbb121ec32742c94fb5d9d6bed8f24d8
> > > > > x86/e820: put !E820_TYPE_RAM regions into memblock.reserved
> > > > >
> > > > > and it was backported to stable, stopping the kernel to boot on my system since around 4.17.4.
> > > > > It was reverted on upstream a couple months ago.
> > > > > commit 2a5bda5a624d6471d25e953b9adba5182ab1b51f upstream
> > > >
> > > > This commit seems not a correct pointer.
> > > > In mainline, commit 124049decbb was reverted by
> > > >
> > > >     commit 9fd61bc95130d4971568b89c9548b5e0a4e18e0e
> > > >     Author: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
> > > >     Date:   Fri Oct 26 15:10:24 2018 -0700
> > > >
> > > >         Revert "x86/e820: put !E820_TYPE_RAM regions into memblock.reserved"
> > > >
> > > > and, the original problem was finally fixed by
> > > >
> > > >     commit 907ec5fca3dc38d37737de826f06f25b063aa08e
> > > >     Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> > > >     Date:   Fri Oct 26 15:10:15 2018 -0700
> > > >
> > > >         mm: zero remaining unavailable struct pages
> > > >
> > > >         Patch series "mm: Fix for movable_node boot option", v3.
> > > >
> > > > so I think both patches should be backported onto v4.17.z.
> > > 
> > > 4.17.y and 4.18.y are long end-of-life, there's nothing I can do there.
> > > 
> > > I can apply the above patches to the 4.19.y tree, is that sufficient?
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > If it were possible to backport it to 4.14 as well. It would be better,
> > but 4.19 is already good.
> > Also, would you port only the revert commit, or also the correct fix for
> > the previous issue?
> > 
> > PD: also, as it was pointed out previously, the correct commit is
> > 9fd61bc95130d4971568b89c9548b5e0a4e18e0e.
> > PD2: sorry about removing the context in the previous mail.
> 
> 9fd61bc95130d4971568b89c9548b5e0a4e18e0e looks like the commit that
> reverts the patch in question, not an additional fix.
> 
> --
> Thanks,
> Sasha
That's right, that commit is the revert. The commit I'm most interested
in getting backported. However, I was referring to the other 3 commits
affecting arch/x86/kernel/e820.c:

7e1c4e27928e memblock: stop using implicit alignment to SMP_CACHE_BYTES
57c8a661d95d mm: remove include/linux/bootmem.h
2a5bda5a624d memblock: replace alloc_bootmem with memblock_alloc

This 3 probably fixed the original issue, for which

124049decbb1 x86/e820: put !E820_TYPE_RAM regions into memblock.reserved

was pushed. I was asking if those 3(or more, if needed) would get
backported as well.
regards

Re: x86: e820 regression

[Sasha Levin]

On Mon, Dec 10, 2018 at 12:15:56PM -0500, Erick Cafferata wrote:
>On 12/10 11:58, Sasha Levin wrote:
>> On Mon, Dec 10, 2018 at 09:21:52AM -0500, Erick Cafferata wrote:
>> > On 12/10 10:49, Greg KH wrote:
>> > > On Mon, Dec 10, 2018 at 08:54:21AM +0000, Naoya Horiguchi wrote:
>> > > > Hi Erick,
>> > > >
>> > > > On Mon, Dec 10, 2018 at 03:28:37AM -0500, Erick Cafferata wrote:
>> > > > > The following commit introduced a regression on my system.
>> > > > >
>> > > > > 124049decbb121ec32742c94fb5d9d6bed8f24d8
>> > > > > x86/e820: put !E820_TYPE_RAM regions into memblock.reserved
>> > > > >
>> > > > > and it was backported to stable, stopping the kernel to boot on my system since around 4.17.4.
>> > > > > It was reverted on upstream a couple months ago.
>> > > > > commit 2a5bda5a624d6471d25e953b9adba5182ab1b51f upstream
>> > > >
>> > > > This commit seems not a correct pointer.
>> > > > In mainline, commit 124049decbb was reverted by
>> > > >
>> > > >     commit 9fd61bc95130d4971568b89c9548b5e0a4e18e0e
>> > > >     Author: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
>> > > >     Date:   Fri Oct 26 15:10:24 2018 -0700
>> > > >
>> > > >         Revert "x86/e820: put !E820_TYPE_RAM regions into memblock.reserved"
>> > > >
>> > > > and, the original problem was finally fixed by
>> > > >
>> > > >     commit 907ec5fca3dc38d37737de826f06f25b063aa08e
>> > > >     Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>> > > >     Date:   Fri Oct 26 15:10:15 2018 -0700
>> > > >
>> > > >         mm: zero remaining unavailable struct pages
>> > > >
>> > > >         Patch series "mm: Fix for movable_node boot option", v3.
>> > > >
>> > > > so I think both patches should be backported onto v4.17.z.
>> > >
>> > > 4.17.y and 4.18.y are long end-of-life, there's nothing I can do there.
>> > >
>> > > I can apply the above patches to the 4.19.y tree, is that sufficient?
>> > >
>> > > thanks,
>> > >
>> > > greg k-h
>> > If it were possible to backport it to 4.14 as well. It would be better,
>> > but 4.19 is already good.
>> > Also, would you port only the revert commit, or also the correct fix for
>> > the previous issue?
>> >
>> > PD: also, as it was pointed out previously, the correct commit is
>> > 9fd61bc95130d4971568b89c9548b5e0a4e18e0e.
>> > PD2: sorry about removing the context in the previous mail.
>>
>> 9fd61bc95130d4971568b89c9548b5e0a4e18e0e looks like the commit that
>> reverts the patch in question, not an additional fix.
>>
>> --
>> Thanks,
>> Sasha
>That's right, that commit is the revert. The commit I'm most interested
>in getting backported. However, I was referring to the other 3 commits
>affecting arch/x86/kernel/e820.c:
>
>7e1c4e27928e memblock: stop using implicit alignment to SMP_CACHE_BYTES
>57c8a661d95d mm: remove include/linux/bootmem.h
>2a5bda5a624d memblock: replace alloc_bootmem with memblock_alloc
>
>This 3 probably fixed the original issue, for which
>
>124049decbb1 x86/e820: put !E820_TYPE_RAM regions into memblock.reserved
>
>was pushed. I was asking if those 3(or more, if needed) would get
>backported as well.
>regards

+ linux-mm@

These commits touch quite a lot of code, and even though they look
simple they are quite invasive, so I wouldn't want to take them without
a proper backport someone tested and acked by the mm folks.

--
Thanks,
Sasha

Re: x86: e820 regression

[Erick Cafferata]

On 12/10 06:10, Sasha Levin wrote:
> On Mon, Dec 10, 2018 at 12:15:56PM -0500, Erick Cafferata wrote:
> > On 12/10 11:58, Sasha Levin wrote:
> > > On Mon, Dec 10, 2018 at 09:21:52AM -0500, Erick Cafferata wrote:
> > > > On 12/10 10:49, Greg KH wrote:
> > > > > On Mon, Dec 10, 2018 at 08:54:21AM +0000, Naoya Horiguchi wrote:
> > > > > > Hi Erick,
> > > > > >
> > > > > > On Mon, Dec 10, 2018 at 03:28:37AM -0500, Erick Cafferata wrote:
> > > > > > > The following commit introduced a regression on my system.
> > > > > > >
> > > > > > > 124049decbb121ec32742c94fb5d9d6bed8f24d8
> > > > > > > x86/e820: put !E820_TYPE_RAM regions into memblock.reserved
> > > > > > >
> > > > > > > and it was backported to stable, stopping the kernel to boot on my system since around 4.17.4.
> > > > > > > It was reverted on upstream a couple months ago.
> > > > > > > commit 2a5bda5a624d6471d25e953b9adba5182ab1b51f upstream
> > > > > >
> > > > > > This commit seems not a correct pointer.
> > > > > > In mainline, commit 124049decbb was reverted by
> > > > > >
> > > > > >     commit 9fd61bc95130d4971568b89c9548b5e0a4e18e0e
> > > > > >     Author: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
> > > > > >     Date:   Fri Oct 26 15:10:24 2018 -0700
> > > > > >
> > > > > >         Revert "x86/e820: put !E820_TYPE_RAM regions into memblock.reserved"
> > > > > >
> > > > > > and, the original problem was finally fixed by
> > > > > >
> > > > > >     commit 907ec5fca3dc38d37737de826f06f25b063aa08e
> > > > > >     Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> > > > > >     Date:   Fri Oct 26 15:10:15 2018 -0700
> > > > > >
> > > > > >         mm: zero remaining unavailable struct pages
> > > > > >
> > > > > >         Patch series "mm: Fix for movable_node boot option", v3.
> > > > > >
> > > > > > so I think both patches should be backported onto v4.17.z.
> > > > >
> > > > > 4.17.y and 4.18.y are long end-of-life, there's nothing I can do there.
> > > > >
> > > > > I can apply the above patches to the 4.19.y tree, is that sufficient?
> > > > >
> > > > > thanks,
> > > > >
> > > > > greg k-h
> > > > If it were possible to backport it to 4.14 as well. It would be better,
> > > > but 4.19 is already good.
> > > > Also, would you port only the revert commit, or also the correct fix for
> > > > the previous issue?
> > > >
> > > > PD: also, as it was pointed out previously, the correct commit is
> > > > 9fd61bc95130d4971568b89c9548b5e0a4e18e0e.
> > > > PD2: sorry about removing the context in the previous mail.
> > > 
> > > 9fd61bc95130d4971568b89c9548b5e0a4e18e0e looks like the commit that
> > > reverts the patch in question, not an additional fix.
> > > 
> > > --
> > > Thanks,
> > > Sasha
> > That's right, that commit is the revert. The commit I'm most interested
> > in getting backported. However, I was referring to the other 3 commits
> > affecting arch/x86/kernel/e820.c:
> > 
> > 7e1c4e27928e memblock: stop using implicit alignment to SMP_CACHE_BYTES
> > 57c8a661d95d mm: remove include/linux/bootmem.h
> > 2a5bda5a624d memblock: replace alloc_bootmem with memblock_alloc
> > 
> > This 3 probably fixed the original issue, for which
> > 
> > 124049decbb1 x86/e820: put !E820_TYPE_RAM regions into memblock.reserved
> > 
> > was pushed. I was asking if those 3(or more, if needed) would get
> > backported as well.
> > regards
> 
> + linux-mm@
> 
> These commits touch quite a lot of code, and even though they look
> simple they are quite invasive, so I wouldn't want to take them without
> a proper backport someone tested and acked by the mm folks.
> 
> --
> Thanks,
> Sasha
I understand. I thought so as well.
Then, at the very least, I'd like to see just the revert commit backported.
And regarding the other commits, if someone else is interested in that,
they can always work on/test that patch I guess.
Thanks

Re: x86: e820 regression

[Sasha Levin]

On Mon, Dec 10, 2018 at 07:01:21PM -0500, Erick Cafferata wrote:
>On 12/10 06:10, Sasha Levin wrote:
>> On Mon, Dec 10, 2018 at 12:15:56PM -0500, Erick Cafferata wrote:
>> > On 12/10 11:58, Sasha Levin wrote:
>> > > On Mon, Dec 10, 2018 at 09:21:52AM -0500, Erick Cafferata wrote:
>> > > > On 12/10 10:49, Greg KH wrote:
>> > > > > On Mon, Dec 10, 2018 at 08:54:21AM +0000, Naoya Horiguchi wrote:
>> > > > > > Hi Erick,
>> > > > > >
>> > > > > > On Mon, Dec 10, 2018 at 03:28:37AM -0500, Erick Cafferata wrote:
>> > > > > > > The following commit introduced a regression on my system.
>> > > > > > >
>> > > > > > > 124049decbb121ec32742c94fb5d9d6bed8f24d8
>> > > > > > > x86/e820: put !E820_TYPE_RAM regions into memblock.reserved
>> > > > > > >
>> > > > > > > and it was backported to stable, stopping the kernel to boot on my system since around 4.17.4.
>> > > > > > > It was reverted on upstream a couple months ago.
>> > > > > > > commit 2a5bda5a624d6471d25e953b9adba5182ab1b51f upstream
>> > > > > >
>> > > > > > This commit seems not a correct pointer.
>> > > > > > In mainline, commit 124049decbb was reverted by
>> > > > > >
>> > > > > >     commit 9fd61bc95130d4971568b89c9548b5e0a4e18e0e
>> > > > > >     Author: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
>> > > > > >     Date:   Fri Oct 26 15:10:24 2018 -0700
>> > > > > >
>> > > > > >         Revert "x86/e820: put !E820_TYPE_RAM regions into memblock.reserved"
>> > > > > >
>> > > > > > and, the original problem was finally fixed by
>> > > > > >
>> > > > > >     commit 907ec5fca3dc38d37737de826f06f25b063aa08e
>> > > > > >     Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>> > > > > >     Date:   Fri Oct 26 15:10:15 2018 -0700
>> > > > > >
>> > > > > >         mm: zero remaining unavailable struct pages
>> > > > > >
>> > > > > >         Patch series "mm: Fix for movable_node boot option", v3.
>> > > > > >
>> > > > > > so I think both patches should be backported onto v4.17.z.
>> > > > >
>> > > > > 4.17.y and 4.18.y are long end-of-life, there's nothing I can do there.
>> > > > >
>> > > > > I can apply the above patches to the 4.19.y tree, is that sufficient?
>> > > > >
>> > > > > thanks,
>> > > > >
>> > > > > greg k-h
>> > > > If it were possible to backport it to 4.14 as well. It would be better,
>> > > > but 4.19 is already good.
>> > > > Also, would you port only the revert commit, or also the correct fix for
>> > > > the previous issue?
>> > > >
>> > > > PD: also, as it was pointed out previously, the correct commit is
>> > > > 9fd61bc95130d4971568b89c9548b5e0a4e18e0e.
>> > > > PD2: sorry about removing the context in the previous mail.
>> > >
>> > > 9fd61bc95130d4971568b89c9548b5e0a4e18e0e looks like the commit that
>> > > reverts the patch in question, not an additional fix.
>> > >
>> > > --
>> > > Thanks,
>> > > Sasha
>> > That's right, that commit is the revert. The commit I'm most interested
>> > in getting backported. However, I was referring to the other 3 commits
>> > affecting arch/x86/kernel/e820.c:
>> >
>> > 7e1c4e27928e memblock: stop using implicit alignment to SMP_CACHE_BYTES
>> > 57c8a661d95d mm: remove include/linux/bootmem.h
>> > 2a5bda5a624d memblock: replace alloc_bootmem with memblock_alloc
>> >
>> > This 3 probably fixed the original issue, for which
>> >
>> > 124049decbb1 x86/e820: put !E820_TYPE_RAM regions into memblock.reserved
>> >
>> > was pushed. I was asking if those 3(or more, if needed) would get
>> > backported as well.
>> > regards
>>
>> + linux-mm@
>>
>> These commits touch quite a lot of code, and even though they look
>> simple they are quite invasive, so I wouldn't want to take them without
>> a proper backport someone tested and acked by the mm folks.
>>
>> --
>> Thanks,
>> Sasha
>I understand. I thought so as well.
>Then, at the very least, I'd like to see just the revert commit backported.
>And regarding the other commits, if someone else is interested in that,
>they can always work on/test that patch I guess.
>Thanks

Sure - I've queued it for 4.19.

Note that 4.14 doesn't have the offending commit to begin with, so
there's nothing to backport (and everything should be working fine for
you).

--
Thanks,
Sasha