Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S969026AbdD1Eqd (ORCPT ); Fri, 28 Apr 2017 00:46:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34550 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966235AbdD1Eq1 (ORCPT ); Fri, 28 Apr 2017 00:46:27 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7AA634E8AB Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=dyoung@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7AA634E8AB Date: Fri, 28 Apr 2017 12:46:19 +0800 From: Dave Young To: AKASHI Takahiro Cc: bhe@redhat.com, vgoyal@redhat.com, bauerman@linux.vnet.ibm.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] kexec: allocate buffer in top-down, if specified, correctly Message-ID: <20170428044619.GA3600@dhcp-128-65.nay.redhat.com> References: <20170426082209.12127-1-takahiro.akashi@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170426082209.12127-1-takahiro.akashi@linaro.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 28 Apr 2017 04:46:26 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2469 Lines: 70 Hi AKASHI On 04/26/17 at 05:22pm, AKASHI Takahiro wrote: > 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. Have you seen actual bug happened or just observing this during code review? Till now seems we do not see any reports about this. > > 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(-) > > 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; > } > > /** > -- > 2.11.1 >