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.8 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 E4AE3C433DB for ; Tue, 2 Mar 2021 09:59:15 +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 5B03C64F0A for ; Tue, 2 Mar 2021 09:59:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5B03C64F0A 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=4Is6qhxG8uMx10FJCBLPoCdT7Ev+1jH7Ji3AlLLINNs=; b=wT/urfxBN81lf7cPtLH45YTwE R5oq08PV5xz4i7StT2dW/M15EHGreHJx3byAZ87DX2am6q0c69QRZDJNBiMV6r5x5q/DrM3NUsCqz Vb7QpTY/p494hsd6xPZA+pcr3PtGH+RVaUK3INyrKlOiNmOOUxr0zVoPLGHkXRGNG9Ct5AA6ej0pV HqvyhYRWU/+hP+cOuWr2ecdt/2RKX6O0z2vD1oY19jiNgLvZumkNgOb4oeWTF/u6WTZ024HTIlW3P a7NrL9HNuTzN/qOMYPXRL7Vrpf8aUdevwN3UyD9aqLfX0IyZzI3Exf9GkHiDeKm93MdE3AFW1JdAZ eYbVOuPmQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lH1mo-00071O-29; Tue, 02 Mar 2021 09:57:50 +0000 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lH1ml-000714-SO for linux-arm-kernel@lists.infradead.org; Tue, 02 Mar 2021 09:57:48 +0000 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 1229aYR1184438; Tue, 2 Mar 2021 04:57:18 -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=yKyKNplrnfGIMREBrT/v98LCI1geLYbB+er4Q6fkd9Q=; b=Jn5lxbK+UhDFunwJyfZ4umAH5vGgxd6IDwt+sEN0mKoA2rO257d89naH37/rhSBWL6yy IoBv5QXi2tI/Qkxmsc71Wx0lAkaEb+anjQGUoghaOXrFzjsGm45NFE1OR/DxE+avxeoR 4i5M8StT1YH1b9k2MUdw3TC9hzaZD5FeeP4hSJuRohOKhHIcxmH0EJqVulwIg6kz6sXU Hzd3G4po0+dCiGSDz3duSqyOvu6THoZt93A7f1WOFrj3UlGtZDvGeZ5k6EZrSR5Zv+Fb 2VtgPSmgdNp7XkDKO8IqvIP5TxlomLA1HZdZm6OeEEvZGVSHkhSlxL+YbwZ7fYobI+Ay 8w== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 371gvtn1hy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 02 Mar 2021 04:57:18 -0500 Received: from m0098417.ppops.net (m0098417.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 1229aqv3185978; Tue, 2 Mar 2021 04:57:17 -0500 Received: from ppma04ams.nl.ibm.com (63.31.33a9.ip4.static.sl-reverse.com [169.51.49.99]) by mx0a-001b2d01.pphosted.com with ESMTP id 371gvtn1gq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 02 Mar 2021 04:57:17 -0500 Received: from pps.filterd (ppma04ams.nl.ibm.com [127.0.0.1]) by ppma04ams.nl.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 1229vECn024285; Tue, 2 Mar 2021 09:57:15 GMT Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by ppma04ams.nl.ibm.com with ESMTP id 3712fmgpx4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 02 Mar 2021 09:57:15 +0000 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 1229vDsg54526246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 2 Mar 2021 09:57:13 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3E643AE053; Tue, 2 Mar 2021 09:57:13 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 88387AE04D; Tue, 2 Mar 2021 09:57:10 +0000 (GMT) Received: from linux.ibm.com (unknown [9.145.23.212]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Tue, 2 Mar 2021 09:57:10 +0000 (GMT) Date: Tue, 2 Mar 2021 11:57:08 +0200 From: Mike Rapoport To: George Kennedy Subject: Re: [PATCH] mm, kasan: don't poison boot memory Message-ID: References: <20210225145700.GC1854360@linux.ibm.com> <20210225160706.GD1854360@linux.ibm.com> <6000e7fd-bf8b-b9b0-066d-23661da8a51d@oracle.com> <20210226111730.GL1854360@linux.ibm.com> <083c2bfd-12dd-f3c3-5004-fb1e3fb6493c@oracle.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-03-02_03:2021-03-01, 2021-03-02 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 priorityscore=1501 clxscore=1011 lowpriorityscore=0 impostorscore=0 bulkscore=0 mlxscore=0 suspectscore=0 mlxlogscore=999 spamscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103020078 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210302_045747_991418_3D82DAE9 X-CRM114-Status: GOOD ( 34.24 ) 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: rafael.j.wysocki@intel.com, David Hildenbrand , Catalin Marinas , Will Deacon , Linux Memory Management List , Alexander Potapenko , Vincenzo Frascino , erik.kaneda@intel.com, robert.moore@intel.com, kasan-dev , Christoph Hellwig , linux-acpi@vger.kernel.org, Dhaval Giani , Andrey Ryabinin , Evgenii Stepanov , lenb@kernel.org, Marco Elver , Andrey Konovalov , Kevin Brodsky , Konrad Rzeszutek Wilk , Peter Collingbourne , Linux ARM , Branislav Rankov , LKML , Dmitry Vyukov , Andrew Morton 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 Hi George, On Mon, Mar 01, 2021 at 08:20:45PM -0500, George Kennedy wrote: > > > > > = > > > > 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. I'd suggest to send it as a formal patch to see what x86 and ACPI folks have to say about this. = > 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) > =A0=A0=A0=A0 cleanup_highmap(); > = > =A0=A0=A0=A0 memblock_set_current_limit(ISA_END_ADDRESS); > +=A0=A0=A0 acpi_boot_table_init(); > =A0=A0=A0=A0 e820__memblock_setup(); > = > =A0=A0=A0=A0 /* > @@ -1140,8 +1141,6 @@ void __init setup_arch(char **cmdline_p) > =A0=A0=A0=A0 /* > =A0=A0=A0=A0 =A0* Parse the ACPI tables for possible boot-time SMP config= uration. > =A0=A0=A0=A0 =A0*/ > -=A0=A0=A0 acpi_boot_table_init(); > - > =A0=A0=A0=A0 early_acpi_boot_init(); > = > =A0=A0=A0=A0 initmem_init(); > diff --git a/drivers/acpi/acpica/tbinstal.c b/drivers/acpi/acpica/tbinsta= l.c > index 0bb15ad..7830109 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" > @@ -16,6 +17,33 @@ > = > =A0/*********************************************************************= ********** > =A0 * > + * FUNCTION:=A0=A0=A0 acpi_tb_reserve_standard_table > + * > + * PARAMETERS:=A0 address=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Table ph= ysical address > + *=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 header=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 - Table header > + * > + * RETURN:=A0=A0=A0=A0=A0 None > + * > + * DESCRIPTION: To avoid an acpi table page from being "stolen" by the > buddy > + *=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 allocator run memblock_reserve= () on all the standard acpi > tables. > + * > + ***********************************************************************= *******/ > +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 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; > + Why these should be excluded? > +=A0=A0=A0 if (header->length > PAGE_SIZE) /* same check as in acpi_map()= */ > +=A0=A0=A0 =A0=A0=A0 return; I don't think this is required, I believe acpi_map() has this check because kmap() cannot handle multiple pages. > + > +=A0=A0=A0 memblock_reserve(address, PAGE_ALIGN(header->length)); > +} > + > +/***********************************************************************= ******** > + * > =A0 * FUNCTION:=A0=A0=A0 acpi_tb_install_table_with_override > =A0 * > =A0 * PARAMETERS:=A0 new_table_desc=A0=A0=A0=A0=A0=A0=A0=A0=A0 - New tabl= e descriptor to install > @@ -58,6 +86,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= ); > = > George -- = Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel