From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1XKohy-0003Rl-JU for kexec@lists.infradead.org; Fri, 22 Aug 2014 13:16:47 +0000 Date: Fri, 22 Aug 2014 09:16:23 -0400 From: Vivek Goyal Subject: Re: kexec fails to boot kernels where CONFIG_RANDOMIZE_BASE=y is set Message-ID: <20140822131623.GI5954@redhat.com> References: <53F11882.3060803@whissi.de> <20140818145718.GD4745@redhat.com> <20140819090724.GB21724@dhcp-17-37.nay.redhat.com> <20140820143315.GC16303@redhat.com> <20140821181000.GB21891@redhat.com> <20140822031941.GB2651@dhcp-17-37.nay.redhat.com> <20140822115902.GA12681@dhcp-16-116.nay.redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140822115902.GA12681@dhcp-16-116.nay.redhat.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Baoquan He Cc: "Thomas D." , Kexec Mailing List , Kees Cook , WANG Chao On Fri, Aug 22, 2014 at 07:59:02PM +0800, Baoquan He wrote: [..] > So we have 2 choices for kexec/kdump: > 1) kexec/kdump kernel need not randomize the kernel starting point. > Since kexec/kdump kernel is only for testing or emergencey, its life is > not too long. > > 2) makes slots around the kernel input addr. This is only useful for > kexec. I can't imagine why kdump need it. > > > > > Hi Thomas, > Could you test below patch? > > > This is patch is from Lu Yinghai. > --- > arch/x86/boot/compressed/misc.c | 14 +++++++++----- > 1 file changed, 9 insertions(+), 5 deletions(-) > > Index: linux-2.6/arch/x86/boot/compressed/misc.c > =================================================================== > --- linux-2.6.orig/arch/x86/boot/compressed/misc.c > +++ linux-2.6/arch/x86/boot/compressed/misc.c > @@ -235,8 +235,9 @@ static void error(char *x) > asm("hlt"); > } > > -#if CONFIG_X86_NEED_RELOCS > -static void handle_relocations(void *output, unsigned long output_len) > +#ifdef CONFIG_X86_NEED_RELOCS > +static void handle_relocations(void *output_orig, void *output, > + unsigned long output_len) > { > int *reloc; > unsigned long delta, map, ptr; > @@ -247,7 +248,7 @@ static void handle_relocations(void *out > * Calculate the delta between where vmlinux was linked to load > * and where it was actually loaded. > */ > - delta = min_addr - LOAD_PHYSICAL_ADDR; > + delta = min_addr - (unsigned long)output_orig; So what does this patch actuall do? If I try to trace back output_orig, it seems to be same as LOAD_PHYSICAL_ADDR. That means there should not be any effect of this change? Or did I not understand it. Look at head_64.S movq $LOAD_PHYSICAL_ADDR, %rbp ... ... movq %rbp, %r8 /* output target address */ call decompress_kernel /* returns kernel location in %rax */ Thanks Vivek _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec