All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Mike Rapoport <rppt@kernel.org>, Roman Gushchin <guro@fb.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
	Kamal Dasu <kdasu.kdev@gmail.com>,
	Serge Semin <Sergey.Semin@baikalelectronics.ru>
Subject: Re: [PATCH v3] MIPS: kernel: Reserve exception base early to prevent corruption
Date: Mon, 8 Mar 2021 20:00:57 +0100	[thread overview]
Message-ID: <20210308190057.GA15111@alpha.franken.de> (raw)
In-Reply-To: <95d12091-d3b0-3034-98ed-9ad73ef21a3b@gmail.com>

On Mon, Mar 08, 2021 at 10:21:10AM -0800, Florian Fainelli wrote:
> On 3/8/21 1:24 AM, Thomas Bogendoerfer wrote:
> > 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 space. Additional we reserve the first 4k (1k for R3k) for
> > either normal exception vector space (legacy CPUs) or special vectors
> > like cache exceptions.
> > 
> > Huge thanks to Serge for analysing and proposing a solution to this
> > issue.
> > 
> > Fixes: 2dcb39645441 ("memblock: do not start bottom-up allocations with kernel_end")
> > Reported-by: Kamal Dasu <kdasu.kdev@gmail.com>
> > Debugged-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> > ---
> > Changes in v3:
> >  - always reserve the first 4k for all CPUs (1k for R3k)
> > 
> > Changes in v2:
> >  - do only memblock reservation in reserve_exception_space()
> >  - reserve 0..0x400 for all CPUs without ebase register and
> >    to addtional reserve_exception_space for BMIPS CPUs
> 
> Thomas, do you mind CC'ing me for subsequent versions so you can get a
> chance to have a Tested-by tag? Thank you!

sure, I hope it's the last version ;-)

> Tested-by: Florian Fainelli <f.fainelli@gmail.com>

thank you.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

  reply	other threads:[~2021-03-08 19:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-08  9:24 [PATCH v3] MIPS: kernel: Reserve exception base early to prevent corruption Thomas Bogendoerfer
2021-03-08 16:37 ` Mike Rapoport
2021-03-08 18:21 ` Florian Fainelli
2021-03-08 19:00   ` Thomas Bogendoerfer [this message]
2021-03-08 20:16 ` Serge Semin
2021-03-09 10:40 ` Thomas Bogendoerfer

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=20210308190057.GA15111@alpha.franken.de \
    --to=tsbogend@alpha.franken.de \
    --cc=Sergey.Semin@baikalelectronics.ru \
    --cc=akpm@linux-foundation.org \
    --cc=f.fainelli@gmail.com \
    --cc=guro@fb.com \
    --cc=kdasu.kdev@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=rppt@kernel.org \
    /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.