From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C6DBBC433DB for ; Sun, 28 Feb 2021 18:09:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3307364E74 for ; Sun, 28 Feb 2021 18:09:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3307364E74 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 523A28D0025; Sun, 28 Feb 2021 13:09:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D3F98D0019; Sun, 28 Feb 2021 13:09:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 39B428D0025; Sun, 28 Feb 2021 13:09:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0227.hostedemail.com [216.40.44.227]) by kanga.kvack.org (Postfix) with ESMTP id 22B5F8D0019 for ; Sun, 28 Feb 2021 13:09:04 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D21F3824999B for ; Sun, 28 Feb 2021 18:09:03 +0000 (UTC) X-FDA: 77868462966.12.2178608 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by imf09.hostedemail.com (Postfix) with ESMTP id 79D29600249E for ; Sun, 28 Feb 2021 18:08:58 +0000 (UTC) Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 11SI4TRM141005; Sun, 28 Feb 2021 13:08:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to; s=pp1; bh=4bb935c/UZyEQhCai159ASVF1c2deNbr/2p5TWhmbJc=; b=YE21XdX46aBFkYH+sul7Ck3aEc2l0vgnZmGUCKfZQ2CaRwZPVfLVpv+vwEFSVj1Ek63z p+y7Y8aCs0OIbCj/QQekJTEBPA15o9aCKHcGOsYDk4N045E/wAuxVQlwzOpS5nFWdVbi CKgWrKtRfQ/aVZgoXfZSdCbWjlyT2BEpSgFe0UMVIvX2soiyB5K6hOjEsZGMAozTn0fl BaXW5MdQaKY60GGZBPit4bv5p23ZiCc8qgCHswTqKg1/pfZjFEZ02/WJkLVvjkDj1LDi 1UxXog3LZMHNPzICgDfUacOFhNPsnJ0jlJLVUFb4Xim3uFTliNYOVn3cTaNVdMWWGqNY IA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 370410w9v2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Feb 2021 13:08:41 -0500 Received: from m0098396.ppops.net (m0098396.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 11SI4iI1141354; Sun, 28 Feb 2021 13:08:40 -0500 Received: from ppma03ams.nl.ibm.com (62.31.33a9.ip4.static.sl-reverse.com [169.51.49.98]) by mx0a-001b2d01.pphosted.com with ESMTP id 370410w9u7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Feb 2021 13:08:40 -0500 Received: from pps.filterd (ppma03ams.nl.ibm.com [127.0.0.1]) by ppma03ams.nl.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 11SI2b3G020519; Sun, 28 Feb 2021 18:08:38 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma03ams.nl.ibm.com with ESMTP id 36ydq893ed-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Feb 2021 18:08:37 +0000 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 11SI8Zsh31588766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 28 Feb 2021 18:08:35 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C302BAE045; Sun, 28 Feb 2021 18:08:35 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7A0D7AE051; Sun, 28 Feb 2021 18:08:33 +0000 (GMT) Received: from linux.ibm.com (unknown [9.145.18.192]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Sun, 28 Feb 2021 18:08:33 +0000 (GMT) Date: Sun, 28 Feb 2021 20:08:31 +0200 From: Mike Rapoport To: George Kennedy Cc: David Hildenbrand , Andrey Konovalov , Andrew Morton , Catalin Marinas , Vincenzo Frascino , Dmitry Vyukov , Konrad Rzeszutek Wilk , Will Deacon , Andrey Ryabinin , Alexander Potapenko , Marco Elver , Peter Collingbourne , Evgenii Stepanov , Branislav Rankov , Kevin Brodsky , Christoph Hellwig , kasan-dev , Linux ARM , Linux Memory Management List , LKML , Dhaval Giani Subject: Re: [PATCH] mm, kasan: don't poison boot memory Message-ID: References: <9b7251d1-7b90-db4f-fa5e-80165e1cbb4b@oracle.com> <20210225085300.GB1854360@linux.ibm.com> <9973d0e2-e28b-3f8a-5f5d-9d142080d141@oracle.com> <20210225145700.GC1854360@linux.ibm.com> <20210225160706.GD1854360@linux.ibm.com> <6000e7fd-bf8b-b9b0-066d-23661da8a51d@oracle.com> <20210226111730.GL1854360@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369,18.0.761 definitions=2021-02-28_07:2021-02-26,2021-02-28 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 phishscore=0 adultscore=0 priorityscore=1501 spamscore=0 impostorscore=0 mlxscore=0 malwarescore=0 mlxlogscore=999 suspectscore=0 lowpriorityscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102280156 X-Stat-Signature: t5a6ctzd8ggcmsip3hc791r59cqjk5d1 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 79D29600249E Received-SPF: none (linux.ibm.com>: No applicable sender policy available) receiver=imf09; identity=mailfrom; envelope-from=""; helo=mx0a-001b2d01.pphosted.com; client-ip=148.163.156.1 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614535738-719371 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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, > >=20 > > On Thu, Feb 25, 2021 at 08:19:18PM -0500, George Kennedy wrote: > > >=20 > > > 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(). > > >=20 > > > virt_to_phys(table) does not seem to return the physical address fo= r 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 wit= h > > early_memremap() which uses different virtual to physical scheme. > >=20 > > I'd say that acpi_tb_find_table_address() makes sense if we'd like to > > reserve ACPI tables outside of drivers/acpi. > >=20 > > But probably we should simply reserve all the tables during > > acpi_table_init() so that any table that firmware put in the normal m= emory > > will be surely reserved. > > > Ran 10 successful boots with the above without failure. > > That's good news indeed :) >=20 > Wondering if we could do something like this instead (trying to keep ch= anges > 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 sa= y if this the best way to reserve the tables. =20 > diff --git a/drivers/acpi/acpica/tbinstal.c b/drivers/acpi/acpica/tbins= tal.c > index 0bb15ad..830f82c 100644 > --- a/drivers/acpi/acpica/tbinstal.c > +++ b/drivers/acpi/acpica/tbinstal.c > @@ -7,6 +7,7 @@ > =A0 * > ***********************************************************************= ******/ >=20 > +#include > =A0#include > =A0#include "accommon.h" > =A0#include "actables.h" > @@ -14,6 +15,23 @@ > =A0#define _COMPONENT=A0=A0=A0=A0=A0=A0=A0=A0=A0 ACPI_TABLES > =A0ACPI_MODULE_NAME("tbinstal") >=20 > +void > +acpi_tb_reserve_standard_table(acpi_physical_address address, > +=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0 struct acpi_table_header *header) > +{ > +=A0=A0=A0 struct acpi_table_header local_header; > + > +=A0=A0=A0 if ((ACPI_COMPARE_NAMESEG(header->signature, ACPI_SIG_FACS))= || > +=A0=A0=A0 =A0=A0=A0 (ACPI_VALIDATE_RSDP_SIG(header->signature))) { > +=A0=A0=A0 =A0=A0=A0 return; > +=A0=A0=A0 } > +=A0=A0=A0 /* Standard ACPI table with full common header */ > + > +=A0=A0=A0 memcpy(&local_header, header, sizeof(struct acpi_table_heade= r)); > + > +=A0=A0=A0 memblock_reserve(address, PAGE_ALIGN(local_header.length)); > +} > + > =A0/*******************************************************************= ************ > =A0 * > =A0 * FUNCTION:=A0=A0=A0 acpi_tb_install_table_with_override > @@ -58,6 +76,9 @@ > =A0=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0=A0 new_table_de= sc->flags, > =A0=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0=A0 new_table_de= sc->pointer); >=20 > +=A0=A0=A0 acpi_tb_reserve_standard_table(new_table_desc->address, > +=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0 new_table_desc->pointer= ); > + > =A0=A0=A0=A0 acpi_tb_print_table_header(new_table_desc->address, > =A0=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0 new_table_desc->point= er); >=20 > There should be no harm in doing the memblock_reserve() for all the sta= ndard > tables, right? It should be ok to memblock_reserve() all the tables very early as long a= s 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. =20 > Ran 10 boots with the above without failure. >=20 > George --=20 Sincerely yours, Mike.