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=-9.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 68284C433E0 for ; Sun, 28 Feb 2021 18:10:55 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 11B4664E54 for ; Sun, 28 Feb 2021 18:10:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 11B4664E54 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=KuJE2mSMu3uuZWMwDf9BsUlW8M8U0CVAyil0Ap6F5Ms=; b=iFXxaPkkOPeHLDpeS8cHH0QQl v2uo8Uwc5nKQrfsENjf+7xvc41LDSoU93mZTpnvBYk3LvaxcCq3EmvaUVY2MFmevI9W7q9aXYyVsU M4iB4V/sm5pwVpl1Y97QfetUEcVZ8ymNpOQ0J+7SN0wBltp08QNKpVVOjt47xkkN/zKWj6vH8dIyu y9yx9pSn5efBAj53NWMjxbDZw02QcI5pkcuaumzeflOzrHvM9/RfclTnUYxindlQq4EivuUKuxXkA k+vfN6EPYz2A1xua+C+QH6rmlgxqzthhW6u3oFMga8lXdIn5aBYc1ZZKMpJ5RiYZnDkYA5IY9uhK9 M9Vw41SGg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lGQV9-0003sE-0R; Sun, 28 Feb 2021 18:09:07 +0000 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lGQV6-0003ra-UC for linux-arm-kernel@lists.infradead.org; Sun, 28 Feb 2021 18:09:05 +0000 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 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-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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210228_130905_132840_A7D477A0 X-CRM114-Status: GOOD ( 36.78 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux ARM , Marco Elver , Dhaval Giani , David Hildenbrand , Andrey Konovalov , Kevin Brodsky , Will Deacon , Branislav Rankov , kasan-dev , LKML , Christoph Hellwig , Andrey Ryabinin , Alexander Potapenko , Evgenii Stepanov , Catalin Marinas , Konrad Rzeszutek Wilk , Andrew Morton , Vincenzo Frascino , Peter Collingbourne , Linux Memory Management List , Dmitry Vyukov Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 ta= ble 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 mem= ory > > 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 chan= ges > 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/tbinsta= l.c > index 0bb15ad..830f82c 100644 > --- a/drivers/acpi/acpica/tbinstal.c > +++ b/drivers/acpi/acpica/tbinstal.c > @@ -7,6 +7,7 @@ > =A0 * > *************************************************************************= ****/ > = > +#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") > = > +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_header)= ); > + > +=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_desc= ->flags, > =A0=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0=A0 new_table_desc= ->pointer); > = > +=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->pointer= ); > = > There should be no harm in doing the memblock_reserve() for all the stand= ard > 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel