Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp195651pxa; Tue, 4 Aug 2020 21:23:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwdhBMDwnYHrzE6t7M0Wo3d8tBABdq3zicDCL8Cg1kWfbaYCWB7EEoqN5UCTXCVkUbMtSMq X-Received: by 2002:a05:6402:758:: with SMTP id p24mr1045516edy.35.1596601399061; Tue, 04 Aug 2020 21:23:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596601399; cv=none; d=google.com; s=arc-20160816; b=JeCgyC+EUPon6ZDNcR9VLNm9dGbsEv0kWhh61O5Vu+mwDKU9GgzKIW+ML5O36Nqfb6 xXgcCgkeft1kP7j58R4yezOzt/85g7ZhhtJthy+EV34HeysEITt58LjEHvEFxSx1/jSB lLOX+9A50QQXNUQgjnPgZLy5fhM/s3Erd0TXU+WkJeY2d8yhmkCCPPFCcT9+U9maun/P rqSCGANgCDtJPehBtHKJWL9C/G0759EEd6gjDyqZnINBzL20TcB+xr4QlzBWBvvN748o e2eHEkdJQCZY+t87Ry9iMnavJOfOITVxbHFglR/e4HeIJtQZ572M+uXEs9FOi8QhqE/5 0ORA== 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:dkim-signature; bh=twertatwzUrM7ldiTnLyq8dIY3NouOKQbE23vgZibYc=; b=gf3MnFglahCZ9H9NdviCNOC+bmVVxdk5jpqI3hbBo3iAJVFVjlgYbOrV4f8Bq2nOZM XHJ5gd2ZzK5ld3J5mhUmg9zIN6teES8QV+EtsVd1K3VBrFWwPsE5SN7TpZmTGmPOUKq7 Kwc5ArYbgkisfSJG066zclklFC4SMhvSYi1xwtbPY9CIhrvIPy4HwK8uTbyubzG4nzd2 sOqnZv4yT+D4aZ0bcY3nn3Q+LwNbXwgZUr/O9ILyQIOijg24GBHGt9hzH7REjSpObJZL WmGtOnYl3xgIsHtgEdAWPl6bpfIv7dOmFZVJcLxsSWNNbLw/HAIjmJbmy8wZqDyZiC9p +C4A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=RhB7tJrW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u29si571397edd.533.2020.08.04.21.22.56; Tue, 04 Aug 2020 21:23:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=RhB7tJrW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725868AbgHEEUj (ORCPT + 99 others); Wed, 5 Aug 2020 00:20:39 -0400 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:52653 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725869AbgHEEUj (ORCPT ); Wed, 5 Aug 2020 00:20:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1596601237; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=twertatwzUrM7ldiTnLyq8dIY3NouOKQbE23vgZibYc=; b=RhB7tJrWsV46yFoehAYmxLRKZCWlHdsxIYJKxQV1BjXImPnPGbcPU6V368xtzPpT8l+y2N KOIzb3ETxq+JUYWFHDfnWn7ZFyX7kyfYNAjP/tGJCSGm5VxuDZQnRtGjoaDq+EoKLy2dTo aEXBlqjVykf8BUIRQmUAnBKVDoaGdv8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-14-pdUQtGUaN4iDPq52ne80Vw-1; Wed, 05 Aug 2020 00:20:34 -0400 X-MC-Unique: pdUQtGUaN4iDPq52ne80Vw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B26651009600; Wed, 5 Aug 2020 04:20:29 +0000 (UTC) Received: from localhost (ovpn-12-71.pek2.redhat.com [10.72.12.71]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2C71071765; Wed, 5 Aug 2020 04:20:27 +0000 (UTC) Date: Wed, 5 Aug 2020 12:20:24 +0800 From: Baoquan He To: Mike Rapoport Cc: Andrew Morton , Andy Lutomirski , Benjamin Herrenschmidt , Borislav Petkov , Catalin Marinas , Christoph Hellwig , Dave Hansen , Emil Renner Berthing , Ingo Molnar , Hari Bathini , Marek Szyprowski , Max Filippov , Michael Ellerman , Michal Simek , Mike Rapoport , Palmer Dabbelt , Paul Mackerras , Paul Walmsley , Peter Zijlstra , Russell King , Stafford Horne , Thomas Gleixner , Will Deacon , Yoshinori Sato , clang-built-linux@googlegroups.com, iommu@lists.linux-foundation.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-c6x-dev@linux-c6x.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, linux-xtensa@linux-xtensa.org, linuxppc-dev@lists.ozlabs.org, openrisc@lists.librecores.org, sparclinux@vger.kernel.org, uclinux-h8-devel@lists.sourceforge.jp, x86@kernel.org Subject: Re: [PATCH v2 13/17] x86/setup: simplify initrd relocation and reservation Message-ID: <20200805042024.GT10792@MiWiFi-R3L-srv> References: <20200802163601.8189-1-rppt@kernel.org> <20200802163601.8189-14-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200802163601.8189-14-rppt@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/02/20 at 07:35pm, Mike Rapoport wrote: > From: Mike Rapoport > > Currently, initrd image is reserved very early during setup and then it > might be relocated and re-reserved after the initial physical memory > mapping is created. The "late" reservation of memblock verifies that mapped > memory size exceeds the size of initrd, the checks whether the relocation ~ then? > required and, if yes, relocates inirtd to a new memory allocated from > memblock and frees the old location. > > The check for memory size is excessive as memblock allocation will anyway > fail if there is not enough memory. Besides, there is no point to allocate > memory from memblock using memblock_find_in_range() + memblock_reserve() > when there exists memblock_phys_alloc_range() with required functionality. > > Remove the redundant check and simplify memblock allocation. > > Signed-off-by: Mike Rapoport > --- > arch/x86/kernel/setup.c | 16 +++------------- > 1 file changed, 3 insertions(+), 13 deletions(-) > > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > index a3767e74c758..d8de4053c5e8 100644 > --- a/arch/x86/kernel/setup.c > +++ b/arch/x86/kernel/setup.c > @@ -262,16 +262,12 @@ static void __init relocate_initrd(void) > u64 area_size = PAGE_ALIGN(ramdisk_size); > > /* We need to move the initrd down into directly mapped mem */ > - relocated_ramdisk = memblock_find_in_range(0, PFN_PHYS(max_pfn_mapped), > - area_size, PAGE_SIZE); > - > + relocated_ramdisk = memblock_phys_alloc_range(area_size, PAGE_SIZE, 0, > + PFN_PHYS(max_pfn_mapped)); > if (!relocated_ramdisk) > panic("Cannot find place for new RAMDISK of size %lld\n", > ramdisk_size); > > - /* Note: this includes all the mem currently occupied by > - the initrd, we rely on that fact to keep the data intact. */ > - memblock_reserve(relocated_ramdisk, area_size); > initrd_start = relocated_ramdisk + PAGE_OFFSET; > initrd_end = initrd_start + ramdisk_size; > printk(KERN_INFO "Allocated new RAMDISK: [mem %#010llx-%#010llx]\n", > @@ -298,13 +294,13 @@ static void __init early_reserve_initrd(void) > > memblock_reserve(ramdisk_image, ramdisk_end - ramdisk_image); > } > + > static void __init reserve_initrd(void) > { > /* Assume only end is not page aligned */ > u64 ramdisk_image = get_ramdisk_image(); > u64 ramdisk_size = get_ramdisk_size(); > u64 ramdisk_end = PAGE_ALIGN(ramdisk_image + ramdisk_size); > - u64 mapped_size; > > if (!boot_params.hdr.type_of_loader || > !ramdisk_image || !ramdisk_size) > @@ -312,12 +308,6 @@ static void __init reserve_initrd(void) > > initrd_start = 0; > > - mapped_size = memblock_mem_size(max_pfn_mapped); > - if (ramdisk_size >= (mapped_size>>1)) > - panic("initrd too large to handle, " > - "disabling initrd (%lld needed, %lld available)\n", > - ramdisk_size, mapped_size>>1); Reviewed-by: Baoquan He > - > printk(KERN_INFO "RAMDISK: [mem %#010llx-%#010llx]\n", ramdisk_image, > ramdisk_end - 1); > > -- > 2.26.2 >