All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: linux-mips@vger.kernel.org
Cc: rppt@kernel.org, fancer.lancer@gmail.com, guro@fb.com,
	akpm@linux-foundation.org, paul@crapouillou.net,
	Florian Fainelli <f.fainelli@gmail.com>,
	Serge Semin <Sergey.Semin@baikalelectronics.ru>,
	Kamal Dasu <kdasu.kdev@gmail.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Yanteng Si <siyanteng@loongson.cn>,
	Huacai Chen <chenhuacai@kernel.org>,
	bcm-kernel-feedback-list@broadcom.com (open list:BROADCOM BMIPS
	MIPS ARCHITECTURE), linux-kernel@vger.kernel.org (open list)
Subject: [PATCH] MIPS: BMIPS: Reserve exception base to prevent corruption
Date: Mon,  1 Mar 2021 20:19:38 -0800	[thread overview]
Message-ID: <20210302041940.3663823-1-f.fainelli@gmail.com> (raw)
In-Reply-To: <20210301092241.i7dxo7zbg3ar55d6@mobilestation>

BMIPS is one of the few platforms that do change the exception base.
After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
with kernel_end") we started seeing BMIPS boards fail to boot with the
built-in FDT being corrupted.

Before the cited commit, early allocations would be in the [kernel_end,
RAM_END] range, but after commit they would be within [RAM_START +
PAGE_SIZE, RAM_END].

The custom exception base handler that is installed by
bmips_ebase_setup() done for BMIPS5000 CPUs ends-up trampling on the
memory region allocated by unflatten_and_copy_device_tree() thus
corrupting the FDT used by the kernel.

To fix this, we need to perform an early reservation of the custom
exception that is going to be installed and this needs to happen at
plat_mem_setup() time to ensure that unflatten_and_copy_device_tree()
finds a space that is suitable, away from reserved memory.

Huge thanks to Serget for analysing and proposing a solution to this
issue.

Fixes: Fixes: 2dcb39645441 ("memblock: do not start bottom-up allocations with kernel_end")
Debugged-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reported-by: Kamal Dasu <kdasu.kdev@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Thomas,

This is intended as a stop-gap solution for 5.12-rc1 and to be picked up
by the stable team for 5.11. We should find a safer way to avoid these
problems for 5.13 maybe.

 arch/mips/bmips/setup.c       | 22 ++++++++++++++++++++++
 arch/mips/include/asm/traps.h |  2 ++
 2 files changed, 24 insertions(+)

diff --git a/arch/mips/bmips/setup.c b/arch/mips/bmips/setup.c
index 31bcfa4e08b9..0088bd45b892 100644
--- a/arch/mips/bmips/setup.c
+++ b/arch/mips/bmips/setup.c
@@ -149,6 +149,26 @@ void __init plat_time_init(void)
 	mips_hpt_frequency = freq;
 }
 
+static void __init bmips_ebase_reserve(void)
+{
+	phys_addr_t base, size = VECTORSPACING * 64;
+
+	switch (current_cpu_type()) {
+	default:
+	case CPU_BMIPS4350:
+		return;
+	case CPU_BMIPS3300:
+	case CPU_BMIPS4380:
+		base = 0x0400;
+		break;
+	case CPU_BMIPS5000:
+		base = 0x1000;
+		break;
+	}
+
+	memblock_reserve(base, size);
+}
+
 void __init plat_mem_setup(void)
 {
 	void *dtb;
@@ -169,6 +189,8 @@ void __init plat_mem_setup(void)
 
 	__dt_setup_arch(dtb);
 
+	bmips_ebase_reserve();
+
 	for (q = bmips_quirk_list; q->quirk_fn; q++) {
 		if (of_flat_dt_is_compatible(of_get_flat_dt_root(),
 					     q->compatible)) {
diff --git a/arch/mips/include/asm/traps.h b/arch/mips/include/asm/traps.h
index 6aa8f126a43d..0ba6bb7f9618 100644
--- a/arch/mips/include/asm/traps.h
+++ b/arch/mips/include/asm/traps.h
@@ -14,6 +14,8 @@
 #define MIPS_BE_FIXUP	1		/* return to the fixup code */
 #define MIPS_BE_FATAL	2		/* treat as an unrecoverable error */
 
+#define VECTORSPACING 0x100	/* for EI/VI mode */
+
 extern void (*board_be_init)(void);
 extern int (*board_be_handler)(struct pt_regs *regs, int is_fixup);
 
-- 
2.25.1


  parent reply	other threads:[~2021-03-02  8:12 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-17 20:12 [PATCH v2 1/2] mm: cma: allocate cma areas bottom-up Roman Gushchin
2020-12-17 20:12 ` [PATCH v2 2/2] memblock: do not start bottom-up allocations with kernel_end Roman Gushchin
2020-12-19 14:52   ` Wonhyuk Yang
2020-12-19 14:52     ` Wonhyuk Yang
2020-12-19 17:05     ` Roman Gushchin
2020-12-20  6:49   ` Mike Rapoport
2021-01-22  4:37     ` Thiago Jung Bauermann
2021-01-22  4:37       ` Thiago Jung Bauermann
2021-01-24  2:09       ` Andrew Morton
2021-01-24  2:09         ` Andrew Morton
2021-01-24  7:34         ` Mike Rapoport
2021-01-24  7:34           ` Mike Rapoport
2021-01-26  0:30           ` Thiago Jung Bauermann
2021-01-26  0:30             ` Thiago Jung Bauermann
2021-02-08 23:58           ` Thiago Jung Bauermann
2021-02-08 23:58             ` Thiago Jung Bauermann
2021-02-28  4:18   ` Florian Fainelli
2021-02-28  9:00     ` Mike Rapoport
2021-02-28 18:19       ` Florian Fainelli
2021-02-28 23:08         ` Serge Semin
2021-03-01  3:50           ` Florian Fainelli
2021-03-01  3:50             ` Florian Fainelli
2021-03-01  9:22             ` Serge Semin
2021-03-01  9:22               ` Serge Semin
2021-03-02  4:09               ` Florian Fainelli
2021-03-02  4:09                 ` Florian Fainelli
2021-03-02 13:26                 ` Serge Semin
2021-03-02  4:19               ` Florian Fainelli [this message]
2021-03-02  8:09                 ` [PATCH] MIPS: BMIPS: Reserve exception base to prevent corruption Mike Rapoport
2021-03-02 13:54                 ` Serge Semin
2021-03-02 19:04                 ` Roman Gushchin
2021-03-02 23:54                 ` Thomas Bogendoerfer
2021-03-03  1:30                   ` Florian Fainelli
2021-03-03  9:41                     ` Thomas Bogendoerfer
2021-03-03 17:45                       ` Maciej W. Rozycki
2021-03-03 18:15                         ` Thomas Bogendoerfer
2021-03-03 21:50                           ` Maciej W. Rozycki
2021-03-01  9:45             ` [PATCH v2 2/2] memblock: do not start bottom-up allocations with kernel_end Mike Rapoport
2021-03-01  9:45               ` Mike Rapoport
2021-03-02  3:55               ` Roman Gushchin
2021-03-02  3:55                 ` Roman Gushchin
2021-03-02 13:08                 ` Serge Semin
2021-03-23 18:19   ` [tip: x86/boot] x86/setup: Consolidate early memory reservations tip-bot2 for Mike Rapoport
2020-12-20  6:48 ` [PATCH v2 1/2] mm: cma: allocate cma areas bottom-up Mike Rapoport
2020-12-21 17:05   ` Roman Gushchin
2020-12-23  4:06     ` Andrew Morton
2020-12-23 16:35       ` Roman Gushchin
2020-12-23 22:10         ` Mike Rapoport
2020-12-28 19:36           ` Roman Gushchin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210302041940.3663823-1-f.fainelli@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=Sergey.Semin@baikalelectronics.ru \
    --cc=akpm@linux-foundation.org \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=chenhuacai@kernel.org \
    --cc=fancer.lancer@gmail.com \
    --cc=guro@fb.com \
    --cc=kdasu.kdev@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=paul@crapouillou.net \
    --cc=rppt@kernel.org \
    --cc=siyanteng@loongson.cn \
    --cc=tsbogend@alpha.franken.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.