Received: by 10.213.65.68 with SMTP id h4csp335775imn; Wed, 21 Mar 2018 20:39:04 -0700 (PDT) X-Google-Smtp-Source: AG47ELvLV5VSDNvtCmkYJQXU39fqsh1FSfYe1vT+ecSJYnIZFpgjdfrriZMFMrVMR+FNBk78bRBt X-Received: by 2002:a17:902:444:: with SMTP id 62-v6mr23788306ple.127.1521689944079; Wed, 21 Mar 2018 20:39:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521689944; cv=none; d=google.com; s=arc-20160816; b=W87+RW5PVo5w1ARxr8ih6L3FYT8hENZEDLdCnhsXffYJVYWWNdxzeC7bWYGY+QnBtL InKvE718wLkLrxh11BVslmrjs2kaRjOYgsMfG+hoiO/xeDbDuiaYv/cAjQ+Xl1D0qOUF PMztYIpMP1PosFuquaGH4xin4saFMhAHwN+dL8LiAqr1MkpyU5S0AZE77ikneMhiJkmC 7pIv6zitXJRs+Vg/a5aDDGCYeOKtptg+2W6HOJS4gCkxZ8JXq/wG3rSs3mfOtktKf8Vk VaaaNtJOr+1OyilDXzIJgCeOKHfLJO4jZA3zgVplkc237tSvwXUThzDpbrkVmm71QimJ 69xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=tFAoIr+X0fJ7l2Y3la/u510bVL/qCphdc54RTGOdgxA=; b=jhdwOH5scV/ke6+DvAnqgF/qoxEvPefGAnAGSnlef01/Fsz6eGlt4Yabnim5BofBk2 2zN52RKa56BS2Cp92T/hapNgetkl+OjZHHg6DjPzq1karkAJhdH+K4oNgt14gmWqg3wg lTdzjio4yp8VaGU4UG3JYBGtE//EjAHfYCzkSW7/NlQZvW96Yj7gSnZ0YtK7BXLE/Sxv MVtxrZsIhlM0CGesKNx0+c6HhmAQ33t3Wun3k/Z61xU4IbbXarwi7RPsbYLK1OPcaZoH ZaqgZhNGoIYzG1OCHxuSwMO+dllj3TE0ULjKzpxbp+pyZPVA8C1Fx/1Z5rH6H3RIwRxI Tpww== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b10-v6si5176657plx.355.2018.03.21.20.38.50; Wed, 21 Mar 2018 20:39:04 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752159AbeCVDhv (ORCPT + 99 others); Wed, 21 Mar 2018 23:37:51 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:39812 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751728AbeCVDhr (ORCPT ); Wed, 21 Mar 2018 23:37:47 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5F0FB8185928; Thu, 22 Mar 2018 03:37:47 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-8-26.pek2.redhat.com [10.72.8.26]) by smtp.corp.redhat.com (Postfix) with ESMTP id DBBBB202322F; Thu, 22 Mar 2018 03:37:42 +0000 (UTC) From: Baoquan He To: linux-kernel@vger.kernel.org Cc: kexec@lists.infradead.org, akpm@linux-foundation.org, takahiro.akashi@linaro.org, ebiederm@xmission.com, vgoyal@redhat.com, dyoung@redhat.com, prudo@linux.vnet.ibm.com, Baoquan He Subject: [PATCH 2/2] kexec_file: Load kernel at top of system RAM if required Date: Thu, 22 Mar 2018 11:37:22 +0800 Message-Id: <20180322033722.9279-3-bhe@redhat.com> In-Reply-To: <20180322033722.9279-1-bhe@redhat.com> References: <20180322033722.9279-1-bhe@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Thu, 22 Mar 2018 03:37:47 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Thu, 22 Mar 2018 03:37:47 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'bhe@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org For kexec_file loading, if kexec_buf.top_down is 'true', the memory which is used to load kernel/initrd/purgatory is supposed to be allocated from top to down. This is also consistent with the old kexec loading interface. However, the current arch_kexec_walk_mem() doesn't do like this. It ignores checking kexec_buf.top_down, bug calls walk_system_ram_res() directly to go through all resources of System RAM, to try to find memory region which can contain the specific kexec buffer, then call locate_mem_hole_callback() to allocate memory in that found memory region from top to down. This is not right. Here add checking if kexec_buf.top_down is 'true' in arch_kexec_walk_mem(), if yes, call the newly added walk_system_ram_res_rev() to find memory region from top to down to load kernel. Signed-off-by: Baoquan He --- kernel/kexec_file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c index 57ec39995b23..76e6307f8971 100644 --- a/kernel/kexec_file.c +++ b/kernel/kexec_file.c @@ -445,6 +445,8 @@ int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf, IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY, crashk_res.start, crashk_res.end, kbuf, func); + else if (kbuf->top_down) + return walk_system_ram_res_rev(0, ULONG_MAX, kbuf, func); else return walk_system_ram_res(0, ULONG_MAX, kbuf, func); } -- 2.13.6