Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp344735yba; Wed, 3 Apr 2019 09:46:12 -0700 (PDT) X-Google-Smtp-Source: APXvYqw9wZygaYqqV2VEtTxzEFeJSUe/bL9vdorOfUru7/2VvYHOPfAelcXmUYXoPwOJGvaBwn+U X-Received: by 2002:a17:902:e110:: with SMTP id cc16mr967309plb.147.1554309972338; Wed, 03 Apr 2019 09:46:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554309972; cv=none; d=google.com; s=arc-20160816; b=YyJdAXsGEZVHPP5g1g0dMD3USCAK8ZkvTRVLFC1qG9pyPTFu6AKzwjVpNZcGxC9TSY OnuCwHWOEYT/yA8u96sifFu/asnbW3YIn8lU0l3tjptMmlTzwj9KdkN5dszFSM+/Qsxd az7pqZDh1GyQt1BtwUW8rKDNMak5POwl2cBLtLjOUsLa2MEy7Ojjiu0i/SJHpnTiFSfZ 4SCuf0/Ey/35d1tajHEwPNA5E5CXMgKP9ZjasYWCM8ohmVjq+i1NRKOCA1fjMPwxJH6X 3XViPj6HYHiLjvcoRpHdSxgZvIlW80SwERmRma/DQ8lYp+vil1EeZJD+0NqP30TEzJph UzCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=IZnHtpKJZJ2fuBkhwsJTbda3w/jemBvyjKtIF9cE10g=; b=evFO88Mh9Pe7avTEg59qtYvVxNKOLpRvkl9/T66lMqpgigoZDZc/3c26ZeVPQO8Y7G 1krlV1hbMkNxOHAqBbWcl9CSAZFWOEkSPzE5NgLsddSRR1MCZkVCwQJez10jGsEUcH91 u9p3Mvp7UA9S6yCey5jAd3PvE/E8UY9j3DmKAKSHTKy1O9c7dei4Wat5XyS6zwKl2FUk syyUdM4c0l2l/xCuULzWa8gkFxm8lpJB3fwOigWpC0wxwNeA9jQaVPcZVs1SlbVFPGtR Gf8YaMmF6GODiY2yzDZsfNt9xPcIQmAEc9KEk1X+gEFbRMDXQ7vWY4PrFXAvWHLGH+WO uFAA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MwXHHRv1; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 14si14109024ple.218.2019.04.03.09.45.57; Wed, 03 Apr 2019 09:46:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MwXHHRv1; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728793AbfDCQok (ORCPT + 99 others); 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-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.