Re: Linux 5.11-rc5

Re: Linux 5.11-rc5

[Linus Torvalds]

On Tue, Jan 26, 2021 at 8:25 AM Mike Rapoport <rppt@linux.ibm.com> wrote:
>
> On Mon, Jan 25, 2021 at 09:46:19PM +0000, Chris Wilson wrote:
> >
> > CI does confirm that the revert of d3921cb8be29 brings the machines back
> > to life.
>
> I still cannot see what could possibly go wrong, so let's revert
> d3921cb8be29 for now and I'll continue to work with Chris to debug this.

Ok, reverted in my tree.

And added stable to the cc, so that they know not to pick up that
commit d3921cb8be29, despite it being marked for stable.

            Linus

Re: Linux 5.11-rc5

[Greg KH]

On Tue, Jan 26, 2021 at 10:45:10AM -0800, Linus Torvalds wrote:
> On Tue, Jan 26, 2021 at 8:25 AM Mike Rapoport <rppt@linux.ibm.com> wrote:
> >
> > On Mon, Jan 25, 2021 at 09:46:19PM +0000, Chris Wilson wrote:
> > >
> > > CI does confirm that the revert of d3921cb8be29 brings the machines back
> > > to life.
> >
> > I still cannot see what could possibly go wrong, so let's revert
> > d3921cb8be29 for now and I'll continue to work with Chris to debug this.
> 
> Ok, reverted in my tree.
> 
> And added stable to the cc, so that they know not to pick up that
> commit d3921cb8be29, despite it being marked for stable.

I've dropped it from the 5.10.y queue now, thanks for letting me know.

greg k-h

Re: Linux 5.11-rc5

[Mike Rapoport]

On Mon, Jan 25, 2021 at 12:49:39PM -0800, Linus Torvalds wrote:
> On Mon, Jan 25, 2021 at 12:35 PM Chris Wilson <chris@chris-wilson.co.uk> wrote:
> 
> Mike: should we perhaps revert the first patch too (commit
> bde9cfa3afe4: "x86/setup: don't remove E820_TYPE_RAM for pfn 0")?

Unfortunately, I was too optimistic and didn't take into account that this
commit changes the way /dev/mem sees the first page of memory.

There were reports of slackware users about issues with lilo after upgrade
from 5.10.11 to 5.10.12

https://www.linuxquestions.org/questions/slackware-14/slackware-current-lilo-vesa-warnings-after-recent-updates-4175689617/#post6214439 

The root cause is that lilo is no longer able to access the first memory
page via /dev/mem because its type was changed from E820_TYPE_RESERVED to
E820_TYPE_RAM, so this became a part of the "System RAM" resource and
devmem_is_allowed() considers it disallowed area.

So here's the revert of bde9cfa3afe4 as well.

From a7fdc4117010d393dd77b99da5b573a5c98453ce Mon Sep 17 00:00:00 2001
From: Mike Rapoport <rppt@linux.ibm.com>
Date: Thu, 4 Feb 2021 20:12:37 +0200
Subject: [PATCH] Revert "x86/setup: don't remove E820_TYPE_RAM for pfn 0"

This reverts commit bde9cfa3afe4324ec251e4af80ebf9b7afaf7afe.

Changing the first memory page type from E820_TYPE_RESERVED to
E820_TYPE_RAM makes it a part of "System RAM" resource rather than a
reserved resource and this in turn causes devmem_is_allowed() to treat is
as area that can be accessed but it is filled with zeroes instead of the
actual data as previously.

The change in /dev/mem output causes lilo to fail as was reported at
slakware users forum [1], and probably other legacy applications will
experience similar problems.

[1] https://www.linuxquestions.org/questions/slackware-14/slackware-current-lilo-vesa-warnings-after-recent-updates-4175689617/#post6214439

Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
 arch/x86/kernel/setup.c | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 3412c4595efd..740f3bdb3f61 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -660,6 +660,17 @@ static void __init trim_platform_memory_ranges(void)
 
 static void __init trim_bios_range(void)
 {
+	/*
+	 * A special case is the first 4Kb of memory;
+	 * This is a BIOS owned area, not kernel ram, but generally
+	 * not listed as such in the E820 table.
+	 *
+	 * This typically reserves additional memory (64KiB by default)
+	 * since some BIOSes are known to corrupt low memory.  See the
+	 * Kconfig help text for X86_RESERVE_LOW.
+	 */
+	e820__range_update(0, PAGE_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
+
 	/*
 	 * special case: Some BIOSes report the PC BIOS
 	 * area (640Kb -> 1Mb) as RAM even though it is not.
@@ -717,15 +728,6 @@ early_param("reservelow", parse_reservelow);
 
 static void __init trim_low_memory_range(void)
 {
-	/*
-	 * A special case is the first 4Kb of memory;
-	 * This is a BIOS owned area, not kernel ram, but generally
-	 * not listed as such in the E820 table.
-	 *
-	 * This typically reserves additional memory (64KiB by default)
-	 * since some BIOSes are known to corrupt low memory.  See the
-	 * Kconfig help text for X86_RESERVE_LOW.
-	 */
 	memblock_reserve(0, ALIGN(reserve_low, PAGE_SIZE));
 }
 	
-- 
2.29.2





>                 Linus

-- 
Sincerely yours,
Mike.

Re: Linux 5.11-rc5

[Linus Torvalds]

On Thu, Feb 4, 2021 at 10:19 AM Mike Rapoport <rppt@linux.ibm.com> wrote:
>
> On Mon, Jan 25, 2021 at 12:49:39PM -0800, Linus Torvalds wrote:
> >
> > Mike: should we perhaps revert the first patch too (commit
> > bde9cfa3afe4: "x86/setup: don't remove E820_TYPE_RAM for pfn 0")?
>
> Unfortunately, I was too optimistic and didn't take into account that this
> commit changes the way /dev/mem sees the first page of memory.
>
> There were reports of slackware users about issues with lilo after upgrade
> from 5.10.11 to 5.10.12

Ok, applied to mainline.

Greg & stable people - this is now commit 5c279c4cf206 ("Revert
"x86/setup: don't remove E820_TYPE_RAM for pfn 0"") in my tree.
Although maybe you just want to revert the commit in stable, rather
than take it from upstream? Same difference.

                 Linus

Re: Linux 5.11-rc5

[Greg KH]

On Thu, Feb 04, 2021 at 10:32:56AM -0800, Linus Torvalds wrote:
> On Thu, Feb 4, 2021 at 10:19 AM Mike Rapoport <rppt@linux.ibm.com> wrote:
> >
> > On Mon, Jan 25, 2021 at 12:49:39PM -0800, Linus Torvalds wrote:
> > >
> > > Mike: should we perhaps revert the first patch too (commit
> > > bde9cfa3afe4: "x86/setup: don't remove E820_TYPE_RAM for pfn 0")?
> >
> > Unfortunately, I was too optimistic and didn't take into account that this
> > commit changes the way /dev/mem sees the first page of memory.
> >
> > There were reports of slackware users about issues with lilo after upgrade
> > from 5.10.11 to 5.10.12
> 
> Ok, applied to mainline.
> 
> Greg & stable people - this is now commit 5c279c4cf206 ("Revert
> "x86/setup: don't remove E820_TYPE_RAM for pfn 0"") in my tree.
> Although maybe you just want to revert the commit in stable, rather
> than take it from upstream? Same difference.

Taking it from upstream makes it easier to track over time what happend.
I've queued it up now, thanks!

greg k-h