From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759592AbbIVTyN (ORCPT ); Tue, 22 Sep 2015 15:54:13 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:53325 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752960AbbIVTyM (ORCPT ); Tue, 22 Sep 2015 15:54:12 -0400 Date: Tue, 22 Sep 2015 12:54:10 -0700 From: Andrew Morton To: Baoquan He Cc: yinghai@kernel.org, dyoung@redhat.com, jroedel@suse.de, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, bp@suse.de, linux-kernel@vger.kernel.org Subject: Re: [Patch v4] Do not reserve crashkernel high memory if crashkernel low memory reserving failed Message-Id: <20150922125410.c7b4e8f47ee7fdf1147e2fa0@linux-foundation.org> In-Reply-To: <1442922494-5677-1-git-send-email-bhe@redhat.com> References: <1442922494-5677-1-git-send-email-bhe@redhat.com> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 22 Sep 2015 19:48:14 +0800 Baoquan He wrote: > People reported that when allocating crashkernel memory using > ",high" and ",low" syntax, there were cases where the reservation > of the "high" portion succeeds, but the reservation of the "low" > portion fails. Then kexec can load kdump kernel successfully, but > the boot of kdump kernel fails as there's no low memory. This is > because allocation of low memory for kdump kernel can fail on large > systems for reasons. E.g it could be manually specified crashkernel > low memory is too large to find in memblock region. > > In this patch add return value for reserve_crashkernel_low. Then > try to reserve crashkernel low memory after crashkernel high memory > has been allocated. If crashkernel low memory reservation failed > free crashkernel high memory and return. User can take measures > when they found kdump kernel cann't be loaded successfully. > > ... > > --- a/arch/x86/kernel/setup.c > +++ b/arch/x86/kernel/setup.c > @@ -493,7 +493,7 @@ static void __init memblock_x86_reserve_range_setup_data(void) > # define CRASH_KERNEL_ADDR_HIGH_MAX MAXMEM > #endif > > -static void __init reserve_crashkernel_low(void) > +static int __init reserve_crashkernel_low(void) > { > #ifdef CONFIG_X86_64 > const unsigned long long alignment = 16<<20; /* 16M */ > @@ -522,17 +522,15 @@ static void __init reserve_crashkernel_low(void) > } else { > /* passed with crashkernel=0,low ? */ > if (!low_size) > - return; > + return 0; What's happening here? It's returning "success" when parse_crashkernel_low() fails? > } > > low_base = memblock_find_in_range(low_size, (1ULL<<32), > low_size, alignment); > > if (!low_base) { > - if (!auto_set) > - pr_info("crashkernel low reservation failed - No suitable area found.\n"); > - > - return; > + pr_info("crashkernel low reservation failed - No suitable area found.\n"); That's not a terribly useful message. If kdump is now unavailable and the operator needs to take some remedial action then we should inform them of this. Also, such a message should have higher severity than KERN_INFO?