linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@linux.ibm.com>
To: George Kennedy <george.kennedy@oracle.com>
Cc: David Hildenbrand <david@redhat.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Will Deacon <will.deacon@arm.com>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Alexander Potapenko <glider@google.com>,
	Marco Elver <elver@google.com>,
	Peter Collingbourne <pcc@google.com>,
	Evgenii Stepanov <eugenis@google.com>,
	Branislav Rankov <Branislav.Rankov@arm.com>,
	Kevin Brodsky <kevin.brodsky@arm.com>,
	Christoph Hellwig <hch@infradead.org>,
	kasan-dev <kasan-dev@googlegroups.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Dhaval Giani <dhaval.giani@oracle.com>
Subject: Re: [PATCH] mm, kasan: don't poison boot memory
Date: Sun, 28 Feb 2021 20:08:31 +0200	[thread overview]
Message-ID: <YDvcH7IY8hV4u2Zh@linux.ibm.com> (raw)
In-Reply-To: <e9e2f1a3-80f2-1b3e-6ffd-8004fe41c485@oracle.com>

On Fri, Feb 26, 2021 at 11:16:06AM -0500, George Kennedy wrote:
> On 2/26/2021 6:17 AM, Mike Rapoport wrote:
> > Hi George,
> > 
> > On Thu, Feb 25, 2021 at 08:19:18PM -0500, George Kennedy wrote:
> > > 
> > > Not sure if it's the right thing to do, but added
> > > "acpi_tb_find_table_address()" to return the physical address of a table to
> > > use with memblock_reserve().
> > > 
> > > virt_to_phys(table) does not seem to return the physical address for the
> > > iBFT table (it would be nice if struct acpi_table_header also had a
> > > "address" element for the physical address of the table).
> >
> > virt_to_phys() does not work that early because then it is mapped with
> > early_memremap()  which uses different virtual to physical scheme.
> > 
> > I'd say that acpi_tb_find_table_address() makes sense if we'd like to
> > reserve ACPI tables outside of drivers/acpi.
> > 
> > But probably we should simply reserve all the tables during
> > acpi_table_init() so that any table that firmware put in the normal memory
> > will be surely reserved.
> > > Ran 10 successful boots with the above without failure.
> > That's good news indeed :)
> 
> Wondering if we could do something like this instead (trying to keep changes
> minimal). Just do the memblock_reserve() for all the standard tables.

I think something like this should work, but I'm not an ACPI expert to say
if this the best way to reserve the tables.
 
> diff --git a/drivers/acpi/acpica/tbinstal.c b/drivers/acpi/acpica/tbinstal.c
> index 0bb15ad..830f82c 100644
> --- a/drivers/acpi/acpica/tbinstal.c
> +++ b/drivers/acpi/acpica/tbinstal.c
> @@ -7,6 +7,7 @@
>   *
> *****************************************************************************/
> 
> +#include <linux/memblock.h>
>  #include <acpi/acpi.h>
>  #include "accommon.h"
>  #include "actables.h"
> @@ -14,6 +15,23 @@
>  #define _COMPONENT          ACPI_TABLES
>  ACPI_MODULE_NAME("tbinstal")
> 
> +void
> +acpi_tb_reserve_standard_table(acpi_physical_address address,
> +               struct acpi_table_header *header)
> +{
> +    struct acpi_table_header local_header;
> +
> +    if ((ACPI_COMPARE_NAMESEG(header->signature, ACPI_SIG_FACS)) ||
> +        (ACPI_VALIDATE_RSDP_SIG(header->signature))) {
> +        return;
> +    }
> +    /* Standard ACPI table with full common header */
> +
> +    memcpy(&local_header, header, sizeof(struct acpi_table_header));
> +
> +    memblock_reserve(address, PAGE_ALIGN(local_header.length));
> +}
> +
>  /*******************************************************************************
>   *
>   * FUNCTION:    acpi_tb_install_table_with_override
> @@ -58,6 +76,9 @@
>                        new_table_desc->flags,
>                        new_table_desc->pointer);
> 
> +    acpi_tb_reserve_standard_table(new_table_desc->address,
> +                   new_table_desc->pointer);
> +
>      acpi_tb_print_table_header(new_table_desc->address,
>                     new_table_desc->pointer);
> 
> There should be no harm in doing the memblock_reserve() for all the standard
> tables, right?

It should be ok to memblock_reserve() all the tables very early as long as
we don't run out of static entries in memblock.reserved.

We just need to make sure the tables are reserved before memblock
allocations are possible, so we'd still need to move acpi_table_init() in
x86::setup_arch() before e820__memblock_setup().
Not sure how early ACPI is initialized on arm64.
 
> Ran 10 boots with the above without failure.
> 
> George

-- 
Sincerely yours,
Mike.


  reply	other threads:[~2021-02-28 18:09 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-17 20:56 [PATCH] mm, kasan: don't poison boot memory Andrey Konovalov
2021-02-18  8:55 ` David Hildenbrand
2021-02-18 19:40   ` Andrey Konovalov
2021-02-18 19:46     ` David Hildenbrand
2021-02-18 20:26       ` Andrey Konovalov
2021-02-19  0:06   ` George Kennedy
2021-02-19  0:09     ` Andrey Konovalov
2021-02-19 16:45       ` George Kennedy
2021-02-19 23:04         ` George Kennedy
2021-02-22  9:52           ` David Hildenbrand
2021-02-22 15:13             ` George Kennedy
2021-02-22 16:13               ` David Hildenbrand
2021-02-22 16:39                 ` David Hildenbrand
2021-02-22 17:40                   ` Konrad Rzeszutek Wilk
2021-02-22 18:45                     ` Mike Rapoport
2021-02-22 18:42                 ` George Kennedy
2021-02-22 21:55                   ` Mike Rapoport
     [not found]                     ` <9773282a-2854-25a4-9faa-9da5dd34e371@oracle.com>
2021-02-23 10:33                       ` Mike Rapoport
     [not found]                         ` <3ef9892f-d657-207f-d4cf-111f98dcb55c@oracle.com>
2021-02-23 15:47                           ` Mike Rapoport
2021-02-23 18:05                             ` George Kennedy
2021-02-23 20:09                               ` Mike Rapoport
2021-02-23 21:16                                 ` George Kennedy
2021-02-23 21:32                                   ` Mike Rapoport
2021-02-23 21:46                                     ` George Kennedy
2021-02-24 10:37                                       ` Mike Rapoport
2021-02-24 14:22                                         ` George Kennedy
2021-02-25  8:53                                           ` Mike Rapoport
2021-02-25 12:38                                             ` George Kennedy
2021-02-25 14:57                                               ` Mike Rapoport
2021-02-25 15:22                                                 ` George Kennedy
2021-02-25 16:06                                                   ` George Kennedy
2021-02-25 16:07                                                   ` Mike Rapoport
2021-02-25 16:31                                                     ` George Kennedy
2021-02-25 17:23                                                       ` David Hildenbrand
2021-02-25 17:41                                                         ` Mike Rapoport
2021-02-25 17:50                                                       ` Mike Rapoport
2021-02-25 17:33                                                     ` George Kennedy
2021-02-26  1:19                                                       ` George Kennedy
2021-02-26 11:17                                                         ` Mike Rapoport
2021-02-26 16:16                                                           ` George Kennedy
2021-02-28 18:08                                                             ` Mike Rapoport [this message]
2021-03-01 14:29                                                               ` George Kennedy
2021-03-02  1:20                                                                 ` George Kennedy
2021-03-02  9:57                                                                   ` Mike Rapoport
2021-02-23 21:26                                 ` George Kennedy

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=YDvcH7IY8hV4u2Zh@linux.ibm.com \
    --to=rppt@linux.ibm.com \
    --cc=Branislav.Rankov@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@google.com \
    --cc=aryabinin@virtuozzo.com \
    --cc=catalin.marinas@arm.com \
    --cc=david@redhat.com \
    --cc=dhaval.giani@oracle.com \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=eugenis@google.com \
    --cc=george.kennedy@oracle.com \
    --cc=glider@google.com \
    --cc=hch@infradead.org \
    --cc=kasan-dev@googlegroups.com \
    --cc=kevin.brodsky@arm.com \
    --cc=konrad@darnok.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pcc@google.com \
    --cc=vincenzo.frascino@arm.com \
    --cc=will.deacon@arm.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).