linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Abbott Liu <liuwenliang@huawei.com>,
	Russell King <linux@armlinux.org.uk>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/6 v14] ARM: Handle a device tree in lowmem
Date: Tue, 6 Oct 2020 11:11:25 +0200	[thread overview]
Message-ID: <CACRpkdaH7=9PC3-yYiB9eyA1wD7=Xwot62DsYiFwD_CmBj6Vzw@mail.gmail.com> (raw)
In-Reply-To: <CAMj1kXFszP5C+y5WdY-nUfX8nEtsg-XUgY_q_A6Y=XMzCiMmwA@mail.gmail.com>

On Mon, Oct 5, 2020 at 4:22 PM Ard Biesheuvel <ardb@kernel.org> wrote:

> I think the problem here may be that early_init_fdt_reserve_self()
> uses the wrong translation for obtaining the PA of the device tree
> blob. This is also the reason we no longer use it on arm64 IIRC.
>
> When I add the following on top, everything works as expected with
> MT_ROM, including the ability to dump the firmware provided DT from
> /sys/firmware/fdt
(...)
> -       if (atags_vaddr)
> +       if (atags_vaddr) {
>                 mdesc = setup_machine_fdt(atags_vaddr);
> +               if (mdesc)
> +                       memblock_reserve(__atags_pointer,
> fdt_totalsize(atags_vaddr));

I tested with this too and it works fine, and makes perfect sense,
it should protect the physical memory used by the DT even if
that happens to be in lowmem.

Please fold this into the patch! (Reviewed/Tested-by).

If we go for copying and unflattening the
devicetree instead of just unflattning it the memblock should
be removed, which is nice and clean to my OCD because
then we don't have this random "hole" in the memory, but I
suspect then we should also drop the virtual mapping and
that seems like it could be hard.

Yours,
Linus Walleij

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

  reply	other threads:[~2020-10-06  9:13 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-01 15:22 [PATCH 0/6 v14] KASan for Arm Linus Walleij
2020-10-01 15:22 ` [PATCH 1/6 v14] ARM: Handle a device tree in lowmem Linus Walleij
2020-10-01 16:45   ` Florian Fainelli
2020-10-01 20:31     ` Linus Walleij
2020-10-02 11:01   ` Ard Biesheuvel
2020-10-04 20:50     ` Linus Walleij
2020-10-05  7:14       ` Ard Biesheuvel
2020-10-05  9:14         ` Ard Biesheuvel
2020-10-05 13:27           ` Linus Walleij
2020-10-05 13:30             ` Linus Walleij
2020-10-05 13:36             ` Ard Biesheuvel
2020-10-05 14:22               ` Ard Biesheuvel
2020-10-06  9:11                 ` Linus Walleij [this message]
2020-10-06  9:16                   ` Ard Biesheuvel
2020-10-06  9:19                     ` Linus Walleij
2020-10-06  8:47           ` Linus Walleij
2020-10-06  8:48             ` Ard Biesheuvel
2020-10-05 12:26         ` Linus Walleij
2020-10-01 15:22 ` [PATCH 2/6 v14] ARM: Disable KASan instrumentation for some code Linus Walleij
2020-10-01 15:22 ` [PATCH 3/6 v14] ARM: Replace string mem* functions for KASan Linus Walleij
2020-10-01 15:22 ` [PATCH 4/6 v14] ARM: Define the virtual space of KASan's shadow region Linus Walleij
2020-10-01 15:22 ` [PATCH 5/6 v14] ARM: Initialize the mapping of KASan shadow memory Linus Walleij
2020-10-01 15:22 ` [PATCH 6/6 v14] ARM: Enable KASan for ARM Linus Walleij
2020-10-01 19:19 ` [PATCH 0/6 v14] KASan for Arm Florian Fainelli
2020-10-01 20:34   ` Linus Walleij
2020-10-01 20:38     ` Florian Fainelli
2020-10-01 21:18   ` Linus Walleij
2020-10-01 21:29     ` Arnd Bergmann
2020-10-01 21:35     ` Florian Fainelli
2020-10-03 15:50   ` Ard Biesheuvel
2020-10-04  8:06     ` Ard Biesheuvel
2020-10-04  8:41       ` Ard Biesheuvel
2020-10-04  9:09         ` Ard Biesheuvel
2020-10-04 20:24           ` Florian Fainelli
2020-10-05  8:40           ` Linus Walleij
2020-10-06 13:21 ` 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='CACRpkdaH7=9PC3-yYiB9eyA1wD7=Xwot62DsYiFwD_CmBj6Vzw@mail.gmail.com' \
    --to=linus.walleij@linaro.org \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=aryabinin@virtuozzo.com \
    --cc=f.fainelli@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=liuwenliang@huawei.com \
    --cc=rppt@linux.ibm.com \
    /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).