From patchwork Wed Apr 26 08:22:09 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 98233 Delivered-To: patch@linaro.org Received: by 10.140.109.52 with SMTP id k49csp209473qgf; Wed, 26 Apr 2017 01:23:09 -0700 (PDT) X-Received: by 10.99.65.4 with SMTP id o4mr30571075pga.90.1493194989773; Wed, 26 Apr 2017 01:23:09 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u24si24577519pfg.209.2017.04.26.01.23.09; Wed, 26 Apr 2017 01:23:09 -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=@linaro.org; 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=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1955502AbdDZIXH (ORCPT + 16 others); Wed, 26 Apr 2017 04:23:07 -0400 Received: from mail-pf0-f179.google.com ([209.85.192.179]:33583 "EHLO mail-pf0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1953141AbdDZITd (ORCPT ); Wed, 26 Apr 2017 04:19:33 -0400 Received: by mail-pf0-f179.google.com with SMTP id a188so38788635pfa.0 for ; Wed, 26 Apr 2017 01:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=DLuRDn55LsQjwSXk9Ix7hhyM+xvpiH+UBWrwmFcIxKg=; b=GxRvN3MlslgGxR9TGPlkgqR5LvAwVEK3onRVipDU2KDmA/GK6wg8E1BAyOym+iweun UHEF2VTwhYUDWHRy1SczNtHhgVPHWPQhj/k60B2waWqgAHiGMEiSkIoP6Qpis723bRr6 72AAB6l4GokiZ/v5U4wLUPlf+a4beBEc8vbv0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=DLuRDn55LsQjwSXk9Ix7hhyM+xvpiH+UBWrwmFcIxKg=; b=gRHGHjUGm8qmWWqhejCXmcNj/OtU8SsucMPQy2U2W45GDFFmaWp1npwFtIPsmS2OHJ Y8TxCx+D/iObAQ2OPyowCNbznALr2aKISiZ8K5TjAO+cqzMChYdpIgE5Hzq4Jmh3GMK8 UXZatyDhBfDFgmYFqwYN3+Ho1Ggn/Bz37uuEPXWKCTSzBmC81cGuisYqswiUXzjVFUVf q/6yB1ffS9l5XTpraXLTUPqhKQNsQW9QQMh49zaxPAh+lxObOjeHtGJ9p+Ki9bpAHAgv XWh4wKiF/p6y1joNFuLxDNeGbtrHGA9Eow4dubjtgnzqgQgPM6QAWVU7eLQOZzzT8s91 D3EA== X-Gm-Message-State: AN3rC/5rUnEBLZ4m5HdzTzJKIk87F8HOGkkZGYJpsLhkD9yx50Q2ViR6 80hXFkAJyTo1XEC6 X-Received: by 10.84.236.79 with SMTP id h15mr34257467pln.110.1493194772364; Wed, 26 Apr 2017 01:19:32 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id q1sm40675217pfc.35.2017.04.26.01.19.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 01:19:31 -0700 (PDT) From: AKASHI Takahiro To: dyoung@redhat.com, bhe@redhat.com Cc: vgoyal@redhat.com, bauerman@linux.vnet.ibm.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, AKASHI Takahiro Subject: [PATCH] kexec: allocate buffer in top-down, if specified, correctly Date: Wed, 26 Apr 2017 17:22:09 +0900 Message-Id: <20170426082209.12127-1-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.11.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The current kexec_locate_mem_hole(kbuf.top_down == 1) stops searching at the first memory region that has enough space for requested size even if some of higher regions may also have. This behavior is not consistent with locate_hole(hole_end == -1) function of kexec-tools. This patch fixes the bug, going though all the memory regions anyway. Signed-off-by: AKASHI Takahiro --- kernel/kexec_file.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) -- 2.11.1 diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c index b118735fea9d..2f131c0d9017 100644 --- a/kernel/kexec_file.c +++ b/kernel/kexec_file.c @@ -373,8 +373,8 @@ static int locate_mem_hole_top_down(unsigned long start, unsigned long end, /* If we are here, we found a suitable memory range */ kbuf->mem = temp_start; - /* Success, stop navigating through remaining System RAM ranges */ - return 1; + /* always return zero, going through all the System RAM ranges */ + return 0; } static int locate_mem_hole_bottom_up(unsigned long start, unsigned long end, @@ -439,18 +439,27 @@ static int locate_mem_hole_callback(u64 start, u64 end, void *arg) * * Return: The memory walk will stop when func returns a non-zero value * and that value will be returned. If all free regions are visited without - * func returning non-zero, then zero will be returned. + * func returning non-zero, then kbuf->mem will be additionally checked + * for top-down search. + * After all, zero will be returned if none of regions fits. */ int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf, int (*func)(u64, u64, void *)) { + int ret; + + kbuf->mem = 0; if (kbuf->image->type == KEXEC_TYPE_CRASH) - return walk_iomem_res_desc(crashk_res.desc, + ret = walk_iomem_res_desc(crashk_res.desc, IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY, crashk_res.start, crashk_res.end, kbuf, func); else - return walk_system_ram_res(0, ULONG_MAX, kbuf, func); + ret = walk_system_ram_res(0, ULONG_MAX, kbuf, func); + + if (!ret && kbuf->mem) + ret = 1; /* found for top-down search */ + return ret; } /**