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: Tue, 23 Feb 2021 12:33:21 +0200 [thread overview]
Message-ID: <20210223103321.GD1741768@linux.ibm.com> (raw)
In-Reply-To: <9773282a-2854-25a4-9faa-9da5dd34e371@oracle.com>
(re-added CC)
On Mon, Feb 22, 2021 at 08:24:59PM -0500, George Kennedy wrote:
>
> On 2/22/2021 4:55 PM, Mike Rapoport wrote:
> > On Mon, Feb 22, 2021 at 01:42:56PM -0500, George Kennedy wrote:
> > > On 2/22/2021 11:13 AM, David Hildenbrand wrote:
> > > > On 22.02.21 16:13, George Kennedy wrote:
> > > >
> > > > The PFN 0xbe453 looks a little strange, though. Do we expect ACPI tables
> > > > close to 3 GiB ? No idea. Could it be that you are trying to map a wrong
> > > > table? Just a guess.
> > > >
> > > > > What would be the correct way to reserve the page so that the above
> > > > > would not be hit?
> > > > I would have assumed that if this is a binary blob, that someone (which
> > > > I think would be acpi code) reserved via memblock_reserve() early during
> > > > boot.
> > > >
> > > > E.g., see drivers/acpi/tables.c:acpi_table_upgrade()->memblock_reserve().
> > > acpi_table_upgrade() gets called, but bails out before memblock_reserve() is
> > > called. Thus, it appears no pages are getting reserved.
> > acpi_table_upgrade() does not actually reserve memory but rather open
> > codes memblock allocation with memblock_find_in_range() +
> > memblock_reserve(), so it does not seem related anyway.
> >
> > Do you have by chance a full boot log handy?
>
> Hello Mike,
>
> Are you after the console output? See attached.
>
> It includes my patch to set PG_Reserved along with the dump_page() debug
> that David asked for - see: "page:"
So, iBFT is indeed at pfn 0xbe453:
[ 0.077698] ACPI: iBFT 0x00000000BE453000 000800 (v01 BOCHS BXPCFACP 00000000 00000000)
and it's in E820_TYPE_RAM region rather than in ACPI data:
[ 0.000000] BIOS-e820: [mem 0x0000000000810000-0x00000000008fffff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x0000000000900000-0x00000000be49afff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000be49b000-0x00000000be49bfff] ACPI data
I could not find anywhere in x86 setup or in ACPI tables parsing the code
that reserves this memory or any other ACPI data for that matter. It could
be that I've missed some copying of the data to statically allocated
initial_tables, but AFAICS any ACPI data that was not marked as such in
e820 tables by BIOS resides in memory that is considered as free.
Can you please check if this hack (entirely untested) changes anything:
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 7bdc0239a943..c118dd54a747 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1551,6 +1551,7 @@ void __init acpi_boot_table_init(void)
if (acpi_disabled)
return;
+#if 0
/*
* Initialize the ACPI boot-time table parser.
*/
@@ -1558,6 +1559,7 @@ void __init acpi_boot_table_init(void)
disable_acpi();
return;
}
+#endif
acpi_table_parse(ACPI_SIG_BOOT, acpi_parse_sbf);
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d883176ef2ce..c8a07a7b9577 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1032,6 +1032,14 @@ void __init setup_arch(char **cmdline_p)
*/
find_smp_config();
+ /*
+ * Initialize the ACPI boot-time table parser.
+ */
+ if (acpi_table_init()) {
+ disable_acpi();
+ return;
+ }
+
reserve_ibft_region();
early_alloc_pgt_buf();
diff --git a/drivers/firmware/iscsi_ibft_find.c b/drivers/firmware/iscsi_ibft_find.c
index 64bb94523281..2e5e04090fe2 100644
--- a/drivers/firmware/iscsi_ibft_find.c
+++ b/drivers/firmware/iscsi_ibft_find.c
@@ -80,6 +80,21 @@ static int __init find_ibft_in_mem(void)
done:
return len;
}
+
+static void __init acpi_find_ibft_region(void)
+{
+ int i;
+ struct acpi_table_header *table = NULL;
+
+ if (acpi_disabled)
+ return;
+
+ for (i = 0; i < ARRAY_SIZE(ibft_signs) && !ibft_addr; i++) {
+ acpi_get_table(ibft_signs[i].sign, 0, &table);
+ ibft_addr = (struct acpi_table_ibft *)table;
+ }
+}
+
/*
* Routine used to find the iSCSI Boot Format Table. The logical
* kernel address is set in the ibft_addr global variable.
@@ -93,6 +108,8 @@ unsigned long __init find_ibft_region(unsigned long *sizep)
if (!efi_enabled(EFI_BOOT))
find_ibft_in_mem();
+ else
+ acpi_find_ibft_region();
if (ibft_addr) {
*sizep = PAGE_ALIGN(ibft_addr->header.length);
> Thank you,
> George
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2021-02-23 10:33 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-17 20:56 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 [this message]
[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
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=20210223103321.GD1741768@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