Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp405107yba; Mon, 1 Apr 2019 08:39:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqzCMr7VCtcKDW8t2LdPX39X5YwBSKUgCYdV93PHya1PaY9uVF7Ilm6PAJQ9LwzRQu5pS6fy X-Received: by 2002:a62:6504:: with SMTP id z4mr28501933pfb.202.1554133174605; Mon, 01 Apr 2019 08:39:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554133174; cv=none; d=google.com; s=arc-20160816; b=CDUJZ39IpEta3/uRqO8Ofo3RAq+bCUtVEbDCkrPXoV1uSzvPWG5vATl7cYiu4MvB9+ d4a2L4k0kjFJ1VBiHlP3nPJjF0KuQalkJnXGhrqlWn0poDTiMTCrZ4vUHXAMTf0fitmS uOlv6tjbkDspwlXbRAeJcgxuocQXiD0OLmMGUH3qUqIx6B+B5Ea7W+Mcq9nItEYwQuIk x1CMjdCOD/utl8Gxo9zoL+hQ76QgG3CzR5atjHRg9qsXF81pdkPsk2+QvdnH+rA7x46B fcj26rtp/wSSOi20jF/s7IvlbT0vMh3U/na4uHFiRkc9H/UCBmbAOY3O5INx0gnLoTxs LC7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=BSKiU4CdGZLaEHDDdXvWEH+6+stwFvziJQhYTbUZiTk=; b=wjsO+6aQj64A6qbXWDOMJesYoqMbRhwI7bwKSyheHaANadmzEB97I9lARCSVAheRKZ OOrgIpQLv1nMOAJji7m8oYel3KgquE6s7ZsaNsEuEWhHFhl8l8W2h7MFH8/uwvbgCjwz 8nXj6u7haslPb644iKkEkKyg5ROPdRUrtoNNhOfDgk9O+r8c2qSsw9iG+A1HjivZllSG 9draY1pm/iX9uGZ3Cy1NMqrQJsMLI5ZUONkQnpAMT6hu7lRsZoIMi9GigvyDqNGtAaZB f7M49SRudvRNR+lECjzyD18r6FztG01gFfbO7yN39k9uFairQOVPgnH+Cc6heQU2nCGN apgQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r10si9022640pgh.395.2019.04.01.08.39.18; Mon, 01 Apr 2019 08:39:34 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728589AbfDAPiP (ORCPT + 99 others); Mon, 1 Apr 2019 11:38:15 -0400 Received: from foss.arm.com ([217.140.101.70]:36818 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726617AbfDAPiO (ORCPT ); Mon, 1 Apr 2019 11:38:14 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 586FCA78; Mon, 1 Apr 2019 08:38:14 -0700 (PDT) Received: from fuggles.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 01E643F690; Mon, 1 Apr 2019 08:38:12 -0700 (PDT) Date: Mon, 1 Apr 2019 16:38:10 +0100 From: Will Deacon To: pierre kuo Cc: Catalin Marinas , Steven Price , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Florian Fainelli , ard.biesheuvel@linaro.org Subject: Re: [PATCH v2 1/1] initrd: move initrd_start calculate within linear mapping range check Message-ID: <20190401153810.GC6884@fuggles.cambridge.arm.com> References: <20190314032047.15790-1-vichy.kuo@gmail.com> <20190319153114.GI59586@arrakis.emea.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1+86 (6f28e57d73f2) () Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [+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. Why isn't it just as simple as the diff below? Will --->8 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);