Received: by 10.213.65.68 with SMTP id h4csp1162340imn; Sat, 7 Apr 2018 19:51:51 -0700 (PDT) X-Google-Smtp-Source: AIpwx49aAnc06CxRYaC7cUgqKYIev9Zf/3ihf8SEU8pdbfXki0ifvNtpF8n+oWC+YODsLof4nQvR X-Received: by 2002:a17:902:8b85:: with SMTP id ay5-v6mr19628plb.0.1523155911860; Sat, 07 Apr 2018 19:51:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523155911; cv=none; d=google.com; s=arc-20160816; b=em4UJ3kYUlql92llphGdTC/G2Bgn1tiJ13p09nOC7optaQFluTiN/upMpOKBTCIVay OwPe/J+/bpDFwRKryeBl14NesRgSafhoPWtmIctj9Jw/k2+UwxMLjasGZX+2vGtamU4a 7QboGuzJtVTEZ0LVDVOBQstNz3f+A9X0c8v4IRLoefj6b9wMso7uaHrne+sow+hNNIRB 1nZSqoBV/O8fwNtOcunZ4RmxfLusbVF5HiFZNwVzuAE3rhd9QVxaxvcyV6vB7RZM7W1n Ji/cKcByTaeXNSszjCkDjfg0gjhpl2tmN68B351sA2FbcohVpF/dfpI3tfb/VGx3qv3g jTEw== 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=vvAX4wSLjQblbEgqrjPZ7LZBBz2/aRpeDebcy2f71Ec=; b=kuW19f23Yl1DAMcBxV2qHvT1kNOzyb5NNplpGHGgDFxJwH2k+TCSbMo4b0O2lkACCh r4aiqd+1qykODRDQZL/SQnoB7Ykt6qy1NUDo9EYbzFLFWzxZHUE1iPM6MSy44Q8Ikh3k VuIcLRCKDby0u/16hGGQ54IItk8faE7r3AbNkEynd0PKd0OfOFi7nMmnizJKzdIFJGKn +5xzpWOSDyO3OhSwWRnIMsm5I/lXdX37utsaoQNwf/C982QuFj2Nnc7mk6UK3V3WeU4p c4djepj/K23hrS83BZP4wltaO5qAcuXijfn/qVJxYP9tFxqPyN9bwYBOHfQFviA3SLCl Modg== 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 n76si5355427pfi.122.2018.04.07.19.51.15; Sat, 07 Apr 2018 19:51:51 -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 S1752734AbeDHCr7 (ORCPT + 99 others); Sat, 7 Apr 2018 22:47:59 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:41808 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752572AbeDHCr5 (ORCPT ); Sat, 7 Apr 2018 22:47:57 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8E237722C3; Sun, 8 Apr 2018 02:47:56 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-8-18.pek2.redhat.com [10.72.8.18]) by smtp.corp.redhat.com (Postfix) with ESMTP id B48FE1102E23; Sun, 8 Apr 2018 02:47:50 +0000 (UTC) From: Baoquan He To: linux-kernel@vger.kernel.org Cc: Baoquan He , Eric Biederman , Vivek Goyal , Dave Young , Andrew Morton , Yinghai Lu , kexec@lists.infradead.org Subject: [PATCH v2 3/3] kexec_file: Load kernel at top of system RAM if required Date: Sun, 8 Apr 2018 10:47:24 +0800 Message-Id: <20180408024724.16812-4-bhe@redhat.com> In-Reply-To: <20180408024724.16812-1-bhe@redhat.com> References: <20180408024724.16812-1-bhe@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Sun, 08 Apr 2018 02:47:56 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Sun, 08 Apr 2018 02:47:56 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.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 what we have been doing all along in the old kexec loading interface and the kexec loading is still default setting in some distributions. However, the current kexec_file loading interface doesn't do likt this. The function arch_kexec_walk_mem() it calls ignores checking kexec_buf.top_down, but calls walk_system_ram_res() directly to go through all resources of System RAM from bottom to up, 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 brings confusion. These two interfaces need be unified on behaviour. 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 Cc: Eric Biederman Cc: Vivek Goyal Cc: Dave Young Cc: Andrew Morton Cc: Yinghai Lu Cc: kexec@lists.infradead.org --- 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