Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Abbott Liu <liuwenliang@huawei.com>,
	kasan-dev <kasan-dev@googlegroups.com>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Alexander Potapenko <glider@google.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Will Deacon <will@kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 4/5 v10] ARM: Initialize the mapping of KASan shadow memory
Date: Tue, 30 Jun 2020 11:38:41 +0200
Message-ID: <CACRpkdb-sHJDRhP-WT+1z3wsVXEvO6_imQvzoosgwLLzNUS60Q@mail.gmail.com> (raw)
In-Reply-To: <20200629143751.GV1551@shell.armlinux.org.uk>

On Mon, Jun 29, 2020 at 4:37 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> On Mon, Jun 29, 2020 at 04:07:06PM +0200, Linus Walleij wrote:
> > Asking for help here!
> >
> > I have a problem with populating PTEs for the LPAE usecase using
> > Versatile Express Cortex A15 (TC1) in QEMU.
> >
> > In this loop of the patch:
> >
> > On Mon, Jun 15, 2020 at 11:05 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > > +static void __init kasan_pte_populate(pmd_t *pmdp, unsigned long addr,
> > > +                                     unsigned long end, int node, bool early)
> > > +{
> > > +       unsigned long next;
> > > +       pte_t *ptep = pte_offset_kernel(pmdp, addr);
> >
> > (...)
> >
> > > +       do {
> > > +               next = pmd_addr_end(addr, end);
> > > +               kasan_pte_populate(pmdp, addr, next, node, early);
> > > +       } while (pmdp++, addr = next, addr != end && pmd_none(READ_ONCE(*pmdp)));
> >
> > I first populate the PMD for 0x6ee00000 .. 0x6f000000
> > and this works fine, and the PTEs are all initialized.
> > pte_offset_kernel() returns something reasonable.
> > (0x815F5000).
> >
> > Next the kernel processes the PMD for
> > 0x6f000000 .. 0x6f200000 and now I run into trouble,
> > because pte_offset_kernel() suddenly returns a NULL
> > pointer 0x00000000.
>
> That means there is no PTE table allocated which covers 0x6f000000.
>
> "pmdp" points at the previous level's table entry that points at the
> pte, and all pte_offset*() does is load that entry, convert it to a
> pte_t pointer type, and point it to the appropriate entry for the
> address.  So, pte_offset*() is an accessor that takes a pointer to
> the preceding level's entry for "addr", and returns a pointer to
> the pte_t entry in the last level of page table for "addr".
>
> It is the responsibility of the caller to pte_offset*() to ensure
> either by explicit tests, or prior knowledge, that pmd_val(*pmdp)
> is a valid PTE table entry.
>
> Since generic kernel code can't use "prior knowledge", it has to do
> the full checks (see, mm/vmalloc.c vunmap_pte_range() and higher
> levels etc using pmd_none_or_clear_bad() for example - whether you
> can use _clear_bad() depends whether you intend to clear "bad" entries.
> Beware that the 1MB sections on non-LPAE will appear as "bad" entries
> since we can't "walk" them to PTE level, and they're certainly not
> "none" entries.)

Spot on! I figured it out quickly with this hint.

Essentially I have some loops like this:

pmd_t *pmdp = pmd_offset(pudp, addr);

if (pmd_none(*pmdp)) {
    void *p = early ? kasan_early_shadow_pte :
kasan_alloc_block(PAGE_SIZE, node);
    ....
}

do {
    pmd_populate_kernel(&init_mm, pmdp, p);
    flush_pmd_entry(pmdp);
    next = pmd_addr_end(addr, end);
    kasan_pte_populate(pmdp, addr, next, node, early);
} while (pmdp++, addr = next, addr != end && pmd_none(READ_ONCE(*pmdp)));

I just had to move the i (pmd_node(*pmdp)) inside the loop and it all
starts working
fine.

What confuses me is that arm64 does it this way (checking pmdp outside the loop)
for all levels of the cache and it works (I suppose?) for them, but I
suspect it is
formally wrong.

I'll rewrite with the check inside the loop at all levels and retest
and resend, then
I hope this starts to work and look reasonable, finally.

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply index

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-15  9:02 [PATCH 0/5 v10] KASan for Arm Linus Walleij
2020-06-15  9:02 ` [PATCH 1/5 v10] ARM: Disable KASan instrumentation for some code Linus Walleij
2020-06-15  9:02 ` [PATCH 2/5 v10] ARM: Replace string mem* functions for KASan Linus Walleij
2020-06-15  9:02 ` [PATCH 3/5 v10] ARM: Define the virtual space of KASan's shadow region Linus Walleij
2020-06-15  9:02 ` [PATCH 4/5 v10] ARM: Initialize the mapping of KASan shadow memory Linus Walleij
2020-06-15 14:33   ` Mike Rapoport
2020-06-30 13:22     ` Linus Walleij
2020-06-30 14:45       ` Mike Rapoport
2020-06-29 14:07   ` Linus Walleij
2020-06-29 14:37     ` Russell King - ARM Linux admin
2020-06-30  9:38       ` Linus Walleij [this message]
2020-06-15  9:02 ` [PATCH 5/5 v10] ARM: Enable KASan for ARM Linus Walleij

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=CACRpkdb-sHJDRhP-WT+1z3wsVXEvO6_imQvzoosgwLLzNUS60Q@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=aryabinin@virtuozzo.com \
    --cc=dvyukov@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=liuwenliang@huawei.com \
    --cc=rppt@linux.ibm.com \
    --cc=will@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

Linux-ARM-Kernel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/0 linux-arm-kernel/git/0.git
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/1 linux-arm-kernel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-kernel linux-arm-kernel/ https://lore.kernel.org/linux-arm-kernel \
		linux-arm-kernel@lists.infradead.org
	public-inbox-index linux-arm-kernel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-arm-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git