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=-3.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,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 28F66C4360F for ; Wed, 3 Apr 2019 16:44:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EB5DE2082C for ; Wed, 3 Apr 2019 16:44:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="MwXHHRv1" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728803AbfDCQok (ORCPT ); Wed, 3 Apr 2019 12:44:40 -0400 Received: from mail-vs1-f68.google.com ([209.85.217.68]:41795 "EHLO mail-vs1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728640AbfDCQoi (ORCPT ); Wed, 3 Apr 2019 12:44:38 -0400 Received: by mail-vs1-f68.google.com with SMTP id g187so10377497vsc.8 for ; Wed, 03 Apr 2019 09:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IZnHtpKJZJ2fuBkhwsJTbda3w/jemBvyjKtIF9cE10g=; b=MwXHHRv1h5zn3S6HC6fai6jO3G3rtmj8JO8H6Jz+9C204Yu46Pn4cYIW9hPe8LoNhU pMDb+l5gi2mKJHXkUc0nOJAzlnJWE321TkYYkHVYSWQBGZvdSpHv6W7qe8GZxSfhaztf GNICr04ymwYTg4bAAtUjuSHkVveNkYvpIxTWJWD5il3RUyaao1KZIa23BSYNM8WFw7pX iuMhTVdPn6uowS8IdDJ41TdWdHPr4yUbGYu4FC0Tp/BZypo9M6XTHGokazScv1T3N55d 8oC/HDkHHDusn9UdKmKYVHamkvad5Z+hE/JLU1SjwPHN4LemW54FPFVngMacgxIt1+fc UTLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IZnHtpKJZJ2fuBkhwsJTbda3w/jemBvyjKtIF9cE10g=; b=LlNUXb8N552B6rzb1QuJBY2/qm/SV92ONqiSATRMM9I4MFumE/n/Mzmzzb5VES0DsL 8/5TRS5QtWim+EKH11D5yrt7V7iB2g7OJazJ2S4oZHJC30XMwwiSuSk3Ol9HBE3ypfet SiMAaci6cv1hGGUpYOLlbDSSWrYkj9DEFrcR2IUDrOqsb+8tY6LXg0F1tjHGqaPp/GgZ 7OxVZx68KX1Y0CxJHeHIRfnpSL2NRVXc80xEswBKjOX5nSZLHs1XEUmjzsKFuCQxEcRh OApBeyF7ZM4UL7uSNg4+EcfXDf6hFdEd+aOo4IviNJ36kFWkIKgkwHwybzUYUyoQ6Hrc kZ6g== X-Gm-Message-State: APjAAAUasYc/fLdQ6q5vqKfcSVLUB2tNVhtXFnmnUkMxs1hbvc4TdsDl l8PREasEeS9bk6p5DNtRRk6DJNmSI2p9Qu3zqR8= X-Google-Smtp-Source: APXvYqz+W8X9zWW0hjnbKwAzSJIl89dxsHD/VXJbVa8vquq1YiaHmYUV7ColocxfIuqgoQxhKpKlTii1d+hleevuVy4= X-Received: by 2002:a67:e256:: with SMTP id w22mr972728vse.173.1554309877071; Wed, 03 Apr 2019 09:44:37 -0700 (PDT) MIME-Version: 1.0 References: <20190314032047.15790-1-vichy.kuo@gmail.com> <20190319153114.GI59586@arrakis.emea.arm.com> <20190401153810.GC6884@fuggles.cambridge.arm.com> In-Reply-To: <20190401153810.GC6884@fuggles.cambridge.arm.com> From: pierre kuo Date: Thu, 4 Apr 2019 00:44:25 +0800 Message-ID: Subject: Re: [PATCH v2 1/1] initrd: move initrd_start calculate within linear mapping range check To: Will Deacon Cc: Catalin Marinas , Steven Price , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Florian Fainelli , ard.biesheuvel@linaro.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org hi Will: > > [+Ard in case I'm missing something] > > On Mon, Apr 01, 2019 at 10:59:53PM +0800, pierre kuo wrote: > > > > With CONFIG_RANDOMIZE_BASE we can get a further change to memstart_addr > > > > after the place where you moved the initrd_{start,end} setting, which > > > > would result in a different value for __phys_to_virt(phys_initrd_start). > > > > > > I found what you mean, since __phys_to_virt will use PHYS_OFFSET > > > (memstart_addr) for calculating. > > > How about moving CONFIG_RANDOMIZE_BASE part of code ahead of > > > CONFIG_BLK_DEV_INITRD checking? > > > > > > That means below (d) moving ahead of (c) > > > prvious: > > > if (memstart_addr + linear_region_size < memblock_end_of_DRAM()) {} ---(a) > > > if (memory_limit != PHYS_ADDR_MAX) {} ---(b) > > > if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && phys_initrd_size) {} ---(c) > > > if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {} ---(d) > > > > > > now: > > > if (memstart_addr + linear_region_size < memblock_end_of_DRAM()) { ---(a) > > > if (memory_limit != PHYS_ADDR_MAX) {} ----------------(b) > > > if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {} --------------(d) > > > if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && phys_initrd_size) {} ---(c) > > > > > > > After tracing the kernel code, > > is it even possible to move CONFIG_RANDOMIZE_BASE part of code ahead > > of memory_limit? > > > > that mean the flow may look like below: > > now2: > > if (memstart_addr + linear_region_size < memblock_end_of_DRAM()) {} ---(a) > > if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {} ---(d) > > if (memory_limit != PHYS_ADDR_MAX) {} ---(b) > > if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && phys_initrd_size) {} ---(c) > > > > in (b), the result of __pa_symbol(_text), memory_limit, > > memblock_mem_limit_remove_map and memblock_add > > are not depended on memsart_addr. > > So the now2 flow can grouping modification of memstart_address, put > > (a) and (d) together. > > I'm afraid that you've lost me with this. welcome for ur kind suggestion ^^ >Why isn't it just as simple as > the diff below? > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > index c29b17b520cd..ec3487c94b10 100644 > --- a/arch/arm64/mm/init.c > +++ b/arch/arm64/mm/init.c > @@ -377,7 +377,7 @@ void __init arm64_memblock_init(void) > base + size > memblock_start_of_DRAM() + > linear_region_size, > "initrd not fully accessible via the linear mapping -- please check your bootloader ...\n")) { > - initrd_start = 0; > + phys_initrd_size = 0; > } else { > memblock_remove(base, size); /* clear MEMBLOCK_ flags */ > memblock_add(base, size); This patch will also fix the issue, but it still needs 2 "if comparisions" for getting initrd_start/initrd_end. By possible grouping modification of memstart_address, and put initrd_start/initrd_end to be calculated only when linear mapping check pass. Maybe (just if) can let the code be more concise. Sincerely appreciate all of yours great comment. 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=-3.7 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=unavailable 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 DADA6C4360F for ; Wed, 3 Apr 2019 16:44:47 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 5FB862082C for ; Wed, 3 Apr 2019 16:44:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="phWgDQLp"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="MwXHHRv1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5FB862082C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ONEwD9RFvRjTvbW/DurwHKoJUQ9J6T4QWTPAvk32GiE=; b=phWgDQLpsh87Jz /4QMd01LUsj8U9WmFLbZYmQ4id5kCIh7alxl8knzi66au1IRMJ78y4LFqpGWRcqiD1z4LWIcBa+39 iDhrtSJyuX8iKK37xIf9wADDQX5LNV2AIcNszVZ1QWdsVbtPRp3tPsk7NWUekUaIWpXCNkZ6reQVt JXKdW6PXYMzdsPx/YHgq16bzj8oQnh3ljDtok6wZNnUXV36DStb2upneIs+XBkfHTTO0gEoek0Qs3 R+9QQIksog4Efscw1aQbp4vKERqwbTDaK2BmbXyYOGYPyAzbRC2s7Ag7l2qAPfSMi9UY5lsRMx9w3 +fvQpDHKCznCbyRWmh3A==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hBj0E-0002GW-Jx; Wed, 03 Apr 2019 16:44:42 +0000 Received: from mail-vs1-xe44.google.com ([2607:f8b0:4864:20::e44]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hBj0B-0002F8-Bc for linux-arm-kernel@lists.infradead.org; Wed, 03 Apr 2019 16:44:40 +0000 Received: by mail-vs1-xe44.google.com with SMTP id a190so10410142vsd.0 for ; Wed, 03 Apr 2019 09:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IZnHtpKJZJ2fuBkhwsJTbda3w/jemBvyjKtIF9cE10g=; b=MwXHHRv1h5zn3S6HC6fai6jO3G3rtmj8JO8H6Jz+9C204Yu46Pn4cYIW9hPe8LoNhU pMDb+l5gi2mKJHXkUc0nOJAzlnJWE321TkYYkHVYSWQBGZvdSpHv6W7qe8GZxSfhaztf GNICr04ymwYTg4bAAtUjuSHkVveNkYvpIxTWJWD5il3RUyaao1KZIa23BSYNM8WFw7pX iuMhTVdPn6uowS8IdDJ41TdWdHPr4yUbGYu4FC0Tp/BZypo9M6XTHGokazScv1T3N55d 8oC/HDkHHDusn9UdKmKYVHamkvad5Z+hE/JLU1SjwPHN4LemW54FPFVngMacgxIt1+fc UTLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IZnHtpKJZJ2fuBkhwsJTbda3w/jemBvyjKtIF9cE10g=; b=JXS/kDS51MRmTZlEtwdVp+LC7yo2aYhtixKQNQ31Dc4ODTnssb9ZuYnCGmIqMWl6jr Oj0VyR4GUs8iv0q6IR2ij4D2MM0dpIPZqw4sdJnKfiYXQ/S4NmL3hQqQe5qYD20wYwyv zXt/ni92pYjU/5d/norpyUNFm/ugvLALsjP6DP49qIrXbkjasYeDi85V2AwyoCIZN/LM fwDRnhlAG4pEt6i7hN8D28gqmU9bufgY8mznZnQx7eAxKgJX03q2xBOsHLiEGogic8EE SfS7E5xwbzaE0gMNVPTPtAoF8Cr8kWZi1mSwQUAB4jJSbca3jLvZ3CTsu9JmU2N8P0Ps Z4Iw== X-Gm-Message-State: APjAAAVAM228UhfVsJDW33JBn83HDjYwRZ6qiAQrgU5uLwIOUeDnr/6c I6himh0eInQKXVZAXYQnPRNRwlLIazNQthP6UJk= X-Google-Smtp-Source: APXvYqz+W8X9zWW0hjnbKwAzSJIl89dxsHD/VXJbVa8vquq1YiaHmYUV7ColocxfIuqgoQxhKpKlTii1d+hleevuVy4= X-Received: by 2002:a67:e256:: with SMTP id w22mr972728vse.173.1554309877071; Wed, 03 Apr 2019 09:44:37 -0700 (PDT) MIME-Version: 1.0 References: <20190314032047.15790-1-vichy.kuo@gmail.com> <20190319153114.GI59586@arrakis.emea.arm.com> <20190401153810.GC6884@fuggles.cambridge.arm.com> In-Reply-To: <20190401153810.GC6884@fuggles.cambridge.arm.com> From: pierre kuo Date: Thu, 4 Apr 2019 00:44:25 +0800 Message-ID: Subject: Re: [PATCH v2 1/1] initrd: move initrd_start calculate within linear mapping range check To: Will Deacon X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190403_094439_417473_54E047DC X-CRM114-Status: GOOD ( 19.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Florian Fainelli , ard.biesheuvel@linaro.org, Catalin Marinas , linux-kernel@vger.kernel.org, Steven Price , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org hi Will: > > [+Ard in case I'm missing something] > > On Mon, Apr 01, 2019 at 10:59:53PM +0800, pierre kuo wrote: > > > > With CONFIG_RANDOMIZE_BASE we can get a further change to memstart_addr > > > > after the place where you moved the initrd_{start,end} setting, which > > > > would result in a different value for __phys_to_virt(phys_initrd_start). > > > > > > I found what you mean, since __phys_to_virt will use PHYS_OFFSET > > > (memstart_addr) for calculating. > > > How about moving CONFIG_RANDOMIZE_BASE part of code ahead of > > > CONFIG_BLK_DEV_INITRD checking? > > > > > > That means below (d) moving ahead of (c) > > > prvious: > > > if (memstart_addr + linear_region_size < memblock_end_of_DRAM()) {} ---(a) > > > if (memory_limit != PHYS_ADDR_MAX) {} ---(b) > > > if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && phys_initrd_size) {} ---(c) > > > if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {} ---(d) > > > > > > now: > > > if (memstart_addr + linear_region_size < memblock_end_of_DRAM()) { ---(a) > > > if (memory_limit != PHYS_ADDR_MAX) {} ----------------(b) > > > if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {} --------------(d) > > > if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && phys_initrd_size) {} ---(c) > > > > > > > After tracing the kernel code, > > is it even possible to move CONFIG_RANDOMIZE_BASE part of code ahead > > of memory_limit? > > > > that mean the flow may look like below: > > now2: > > if (memstart_addr + linear_region_size < memblock_end_of_DRAM()) {} ---(a) > > if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {} ---(d) > > if (memory_limit != PHYS_ADDR_MAX) {} ---(b) > > if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && phys_initrd_size) {} ---(c) > > > > in (b), the result of __pa_symbol(_text), memory_limit, > > memblock_mem_limit_remove_map and memblock_add > > are not depended on memsart_addr. > > So the now2 flow can grouping modification of memstart_address, put > > (a) and (d) together. > > I'm afraid that you've lost me with this. welcome for ur kind suggestion ^^ >Why isn't it just as simple as > the diff below? > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > index c29b17b520cd..ec3487c94b10 100644 > --- a/arch/arm64/mm/init.c > +++ b/arch/arm64/mm/init.c > @@ -377,7 +377,7 @@ void __init arm64_memblock_init(void) > base + size > memblock_start_of_DRAM() + > linear_region_size, > "initrd not fully accessible via the linear mapping -- please check your bootloader ...\n")) { > - initrd_start = 0; > + phys_initrd_size = 0; > } else { > memblock_remove(base, size); /* clear MEMBLOCK_ flags */ > memblock_add(base, size); This patch will also fix the issue, but it still needs 2 "if comparisions" for getting initrd_start/initrd_end. By possible grouping modification of memstart_address, and put initrd_start/initrd_end to be calculated only when linear mapping check pass. Maybe (just if) can let the code be more concise. Sincerely appreciate all of yours great comment. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel