lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 20 Dec 2010 17:31:19 +0100 From: Stanislaw Gruszka <sgruszka@...hat.com> To: "H. Peter Anvin" <hpa@...or.com> Cc: Vivek Goyal <vgoyal@...hat.com>, Yinghai Lu <yinghai@...nel.org>, Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>, Maxim Uvarov <muvarov@...il.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Neil Horman <nhorman@...hat.com> Subject: Re: kdump broken on 2.6.37-rc4 On Fri, Dec 17, 2010 at 11:56:23AM -0800, H. Peter Anvin wrote: > On 12/17/2010 11:50 AM, Vivek Goyal wrote: > > On Fri, Dec 17, 2010 at 11:46:08AM -0800, Yinghai Lu wrote: > >> On 12/17/2010 11:39 AM, H. Peter Anvin wrote: > >>> On 12/17/2010 10:21 AM, Yinghai Lu wrote: > >>>>>> > >>>>>> Do we have actual testing for how high the 64-bit kernel will load? > >>>>> > >>>>> I will do some experiments on my box today and let you know. > >>>> > >>>> if bzImage is used, it is 896M. > >>>> > >>> > >>> Why? 896 MiB is a 32-bit kernel limitation which doesn't have anything > >>> to do with the bzImage format. > >>> > >>> So unless there is something going on here, I suspect you're just plain > >>> flat wrong. > >> > >> kexec-tools have some checking when it loads bzImage. > >> > > > > Yinghai, > > > > I think x86_64 might have just inherited the settings of 32bit without > > giving it too much of thought. At that point of time nobody bothered > > to load the kernel from high addresses. So these might be artificial > > limits. > > > > Can we do this in the meantime, just so we fix the immediate problem? > > -hpa I'm not sure what going on, but I can no logner reproduce kdump problem with -rc6 on my T-500 x86_64 system. I tested below patch together with previous patch "x86-32: Make sure we can map all of lowmem if we need to", and on my both laptops i686 and x86_64 system boots and kdump works. Stanislaw > From 1ec83ca8dcc85bc5810bf7407d470a7261be1372 Mon Sep 17 00:00:00 2001 > From: H. Peter Anvin <hpa@...ux.intel.com> > Date: Thu, 16 Dec 2010 19:20:41 -0800 > Subject: [PATCH] x86, kexec: Limit the crashkernel address to 768 MiB > > Keep the crash kernel address below 768 MiB. This makes it work on > 32 bits even if the vmalloc= setting is adjusted slightly. > > For 64 bits, we should be able to increase this substantially once a > hard-coded 896 MiB limit in kexec-tools is fixed. > > Signed-off-by: H. Peter Anvin <hpa@...ux.intel.com> > Cc: Vivek Goyal <vgoyal@...hat.com> > Cc: Stanislaw Gruszka <sgruszka@...hat.com> > Cc: Yinghai Lu <yinghai@...nel.org> > LKML-Reference: <20101217195035.GE14502@...hat.com> > --- > arch/x86/kernel/setup.c | 13 ++++++++++--- > 1 files changed, 10 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > index 21c6746..2b7f5ab 100644 > --- a/arch/x86/kernel/setup.c > +++ b/arch/x86/kernel/setup.c > @@ -501,7 +501,14 @@ static inline unsigned long long get_total_mem(void) > return total << PAGE_SHIFT; > } > > -#define DEFAULT_BZIMAGE_ADDR_MAX 0x37FFFFFF > +/* > + * Keep the crash kernel below this limit. This should be sufficient > + * to load a 32-bit kernel even if the vmalloc limit is modified > + * (within reason.) This can be increased on 64 bits once kexec-tools > + * is fixed. > + */ > +#define CRASH_KERNEL_ADDR_MAX (768 << 20) > + > static void __init reserve_crashkernel(void) > { > unsigned long long total_mem; > @@ -520,10 +527,10 @@ static void __init reserve_crashkernel(void) > const unsigned long long alignment = 16<<20; /* 16M */ > > /* > - * kexec want bzImage is below DEFAULT_BZIMAGE_ADDR_MAX > + * kexec want bzImage is below CRASH_KERNEL_ADDR_MAX > */ > crash_base = memblock_find_in_range(alignment, > - DEFAULT_BZIMAGE_ADDR_MAX, crash_size, alignment); > + CRASH_KERNEL_ADDR_MAX, crash_size, alignment); > > if (crash_base == MEMBLOCK_ERROR) { > pr_info("crashkernel reservation failed - No suitable area found.\n"); > -- > 1.7.2.3 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists