linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: George Kennedy <george.kennedy@oracle.com>
To: Mike Rapoport <rppt@linux.ibm.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>,
	robert.moore@intel.com, erik.kaneda@intel.com,
	rafael.j.wysocki@intel.com, lenb@kernel.org,
	linux-acpi@vger.kernel.org
Subject: Re: [PATCH] mm, kasan: don't poison boot memory
Date: Mon, 1 Mar 2021 20:20:45 -0500	[thread overview]
Message-ID: <a8864397-83e8-61f7-4b9a-33716eca6cf8@oracle.com> (raw)
In-Reply-To: <083c2bfd-12dd-f3c3-5004-fb1e3fb6493c@oracle.com>



On 3/1/2021 9:29 AM, George Kennedy wrote:
>
>
> On 2/28/2021 1:08 PM, Mike Rapoport wrote:
>> 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.
> Adding ACPI maintainers to the CC list.
>>> 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.
>
> Thanks Mike. Will try to move the memblock_reserves() before 
> e820__memblock_setup().

Hi Mike,

Moved acpi_table_init() in x86::setup_arch() before 
e820__memblock_setup() as you suggested.

Ran 10 boots with the following without error.

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 740f3bdb..3b1dd24 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1047,6 +1047,7 @@ void __init setup_arch(char **cmdline_p)
      cleanup_highmap();

      memblock_set_current_limit(ISA_END_ADDRESS);
+    acpi_boot_table_init();
      e820__memblock_setup();

      /*
@@ -1140,8 +1141,6 @@ void __init setup_arch(char **cmdline_p)
      /*
       * Parse the ACPI tables for possible boot-time SMP configuration.
       */
-    acpi_boot_table_init();
-
      early_acpi_boot_init();

      initmem_init();
diff --git a/drivers/acpi/acpica/tbinstal.c b/drivers/acpi/acpica/tbinstal.c
index 0bb15ad..7830109 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"
@@ -16,6 +17,33 @@

  /*******************************************************************************
   *
+ * FUNCTION:    acpi_tb_reserve_standard_table
+ *
+ * PARAMETERS:  address             - Table physical address
+ *              header              - Table header
+ *
+ * RETURN:      None
+ *
+ * DESCRIPTION: To avoid an acpi table page from being "stolen" by the 
buddy
+ *              allocator run memblock_reserve() on all the standard 
acpi tables.
+ *
+ 
******************************************************************************/
+void
+acpi_tb_reserve_standard_table(acpi_physical_address address,
+               struct acpi_table_header *header)
+{
+    if ((ACPI_COMPARE_NAMESEG(header->signature, ACPI_SIG_FACS)) ||
+        (ACPI_VALIDATE_RSDP_SIG(header->signature)))
+        return;
+
+    if (header->length > PAGE_SIZE) /* same check as in acpi_map() */
+        return;
+
+    memblock_reserve(address, PAGE_ALIGN(header->length));
+}
+
+/*******************************************************************************
+ *
   * FUNCTION:    acpi_tb_install_table_with_override
   *
   * PARAMETERS:  new_table_desc          - New table descriptor to install
@@ -58,6 +86,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);

George

>
> George
>>> Ran 10 boots with the above without failure.
>>>
>>> George
>



  reply	other threads:[~2021-03-02  1:21 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
2021-03-01 14:29                                                               ` George Kennedy
2021-03-02  1:20                                                                 ` George Kennedy [this message]
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=a8864397-83e8-61f7-4b9a-33716eca6cf8@oracle.com \
    --to=george.kennedy@oracle.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=erik.kaneda@intel.com \
    --cc=eugenis@google.com \
    --cc=glider@google.com \
    --cc=hch@infradead.org \
    --cc=kasan-dev@googlegroups.com \
    --cc=kevin.brodsky@arm.com \
    --cc=konrad@darnok.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pcc@google.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=robert.moore@intel.com \
    --cc=rppt@linux.ibm.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).