From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Quanyang Wang <quanyang.wang@windriver.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ARM: add BUILD_BUG_ON to check if fixmap range spans multiple pmds
Date: Tue, 26 Oct 2021 11:54:56 +0100 [thread overview]
Message-ID: <YXfegIP+Xamfcnfp@shell.armlinux.org.uk> (raw)
In-Reply-To: <8905597e-49a9-c898-c78d-3d2f51180133@windriver.com>
On Tue, Oct 26, 2021 at 06:38:16PM +0800, Quanyang Wang wrote:
> Hi Ard,
>
> On 10/26/21 6:12 PM, Ard Biesheuvel wrote:
> > On Tue, 26 Oct 2021 at 11:53, Quanyang Wang <quanyang.wang@windriver.com> wrote:
> > >
> > > Hi,
> > > Sorry for the inconvenience.
> > >
> > > On 10/26/21 4:59 PM, Russell King (Oracle) wrote:
> > > > On Sun, Oct 24, 2021 at 11:44:31PM +0200, Linus Walleij wrote:
> > > > > On Wed, Oct 20, 2021 at 7:50 AM <quanyang.wang@windriver.com> wrote:
> > > > >
> > > > > > From: Quanyang Wang <quanyang.wang@windriver.com>
> > > > > >
> > > > > > Not only the early fixmap range, but also the fixmap range should be
> > > > > > checked if it spans multiple pmds. When enabling CONFIG_DEBUG_HIGHMEM,
> > > > > > some systems which contain up to 16 CPUs will crash.
> > > > > >
> > > > > > Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com>
> > > > >
> > > > > Looks reasonable to me.
> > > > > Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> > > > >
> > > > > Please submit this patch into Russell's patch tracker.
> > > >
> > > > ... and has totally broken what looks like _all_ ARM kernel builds.
> > > This patch is intended to trigger build error when it check the value of
> > > __end_of_fixmap_region is equal or larger than 256.
> >
> > Why? The fixmap region is larger than one PMD, so why do we need to cap it?
> In __kmap_local_pfn_prot, arch_kmap_local_set_pte(&init_mm, vaddr, kmap_pte
> - idx, pteval) is used to set pteval.
> But the ptep is calculated by "kmap_pte - idx", which means all ptes must be
> placed next to each other and no gaps. But for ARM, the ptes for the range
> "0xffe00000~0xfff00000" is not next to the ptes for the range
> "0xffc80000~0xffdfffff".
>
> When the idx is larger than 256, virtual address is in 0xffdxxxxx, access
> this address will crash since its pteval isn't set correctly.
Thanks for the explanation.
Sadly, this does seem to be correct. Even if the PTE tables are
located next to each other in memory, they _still_ won't be a
contiguous array of entries due to being interleaved with the Linux
PTE table and the hardware PTE table.
Since the address range 0xffe00000-0xfff00000 is already half of one
PTE table containing 512 contiguous entries, we are limited to 256
fixmap PTEs maximum. If we have more than that we will start trampling
over memory below the PTE table _and_ we will start corrupting Linux
PTE entries in the 0xfff00000-0xffffffff range.
I suspect this hasn't been seen because of a general lack of ARM
systems with more than 4 CPUs.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-10-26 10:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-20 5:49 [PATCH] ARM: add BUILD_BUG_ON to check if fixmap range spans multiple pmds quanyang.wang
2021-10-24 21:44 ` Linus Walleij
2021-10-25 6:38 ` Quanyang Wang
2021-10-26 8:59 ` Russell King (Oracle)
2021-10-26 9:53 ` Quanyang Wang
2021-10-26 10:12 ` Ard Biesheuvel
2021-10-26 10:38 ` Quanyang Wang
2021-10-26 10:54 ` Russell King (Oracle) [this message]
2021-10-26 10:56 ` Ard Biesheuvel
2021-10-26 11:15 ` Russell King (Oracle)
2021-10-26 11:26 ` Ard Biesheuvel
2021-10-26 11:29 ` Russell King (Oracle)
2021-10-31 18:12 ` kernel test robot
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=YXfegIP+Xamfcnfp@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=ardb@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quanyang.wang@windriver.com \
--cc=tglx@linutronix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).