All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mohan Kumar M <mohan@in.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: ppcdev <linuxppc-dev@ozlabs.org>, kexec@lists.infradead.org
Subject: Re: [PATCH] Support for relocatable kdump kernel
Date: Thu, 09 Oct 2008 22:05:22 +0530	[thread overview]
Message-ID: <48EE32CA.5070401@in.ibm.com> (raw)
In-Reply-To: <18669.38444.112286.785452@cargo.ozlabs.ibm.com>

Hi Paul,

Thank you for the review. I will implement the changes you suggested and 
send the patches.

Regards,
Mohan.

> Mohan Kumar M writes:
> 
>> Support for relocatable kdump kernel
> 
> [snip]
> 
>> @@ -1384,7 +1392,15 @@ _STATIC(__after_prom_start)
>>  	/* process relocations for the final address of the kernel */
>>  	lis	r25,PAGE_OFFSET@highest	/* compute virtual base of kernel */
>>  	sldi	r25,r25,32
>> -	mr	r3,r25
>> +#ifdef CONFIG_CRASH_DUMP
>> +	ld	r7,__kdump_flag@got(r2)
>> +	add	r7,r7,r26
>> +	ld	r7,0(r7)
> 
> I think it is dangerous to use an address from the GOT at this point
> when we haven't called relocate() yet.  In fact those 3 instructions
> can be replaced by one:
> 
> 	ld	r7,__kdump_flag-_stext(r26)
> 
> since we have our base address (i.e. the address of _stext) in r26 at
> this point.
> 
>> +#ifdef CONFIG_RELOCATABLE
>> +#ifdef CONFIG_CRASH_DUMP
>> +/*
>> + * Check if the kernel has to be running as relocatable kernel based on the
>> + * variable __kdump_flag, if it is set the kernel is treated as relocatble
>> + * kernel, otherwise it will be moved to PHYSICAL_START
>> + */
>> +	ld	r7,__kdump_flag@got(r2)
>> +	ld	r7,0(r7)
> 
> Here again I would rather you did
> 
> 	ld	r7,__kdump_flag-_stext(r26)
> 
> since the kernel is relocated for its final location by this point,
> but it is not running at the final location yet.
> 
>> +	cmpldi	cr0,r7,1
>> +	bne	regular
>> +
>> +	li	r5,__end_interrupts - _stext	/* just copy interrupts */
>> +	b	5f
>> +regular:
>> +#endif
>> +	lis	r5,(copy_to_here - _stext)@ha
>> +	addi	r5,r5,(copy_to_here - _stext)@l /* # bytes of memory to copy */
>>  
>>  	bl	.copy_and_flush		/* copy the first n bytes	 */
>>  					/* this includes the code being	 */
>> @@ -1411,15 +1443,33 @@ _STATIC(__after_prom_start)
>>  	mtctr	r8
>>  	bctr
>>  
>> +p_end:	.llong	_end - _stext
>> +
>>  4:	/* Now copy the rest of the kernel up to _end */
>>  	addis	r5,r26,(p_end - _stext)@ha
>>  	ld	r5,(p_end - _stext)@l(r5)	/* get _end */
>> -	bl	.copy_and_flush		/* copy the rest */
>> +#else
>> +	lis	r5,(copy_to_here - _stext)@ha
>> +	addi	r5,r5,(copy_to_here - _stext)@l /* # bytes of memory to copy */
>>  
>> -9:	b	.start_here_multiplatform
>> +	bl	.copy_and_flush		/* copy the first n bytes	 */
>> +					/* this includes the code being	 */
>> +					/* executed here.		 */
>> +	addis	r8,r3,(4f - _stext)@ha	/* Jump to the copy of this code */
>> +	addi	r8,r8,(4f - _stext)@l	/* that we just made */
>> +	mtctr	r8
>> +	bctr
>>  
>>  p_end:	.llong	_end - _stext
>>  
>> +4:	/* Now copy the rest of the kernel up to _end */
>> +	addis	r5,r26,(p_end - _stext)@ha
>> +	ld	r5,(p_end - _stext)@l(r5)	/* get _end */
>> +#endif
>> +5:	bl	.copy_and_flush		/* copy the rest */
>> +
>> +9:	b	.start_here_multiplatform
> 
> You have ended up with two separate copies of the code here depending
> on whether or not we have CONFIG_RELOCATABLE set.  I don't think the
> code paths should be different to such an extent.  Please try to make
> the ifdef as small as possible (ideally, nonexistent).
> 
> Paul.
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Mohan Kumar M <mohan@in.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: ppcdev <linuxppc-dev@ozlabs.org>, kexec@lists.infradead.org
Subject: Re: [PATCH] Support for relocatable kdump kernel
Date: Thu, 09 Oct 2008 22:05:22 +0530	[thread overview]
Message-ID: <48EE32CA.5070401@in.ibm.com> (raw)
In-Reply-To: <18669.38444.112286.785452@cargo.ozlabs.ibm.com>

Hi Paul,

Thank you for the review. I will implement the changes you suggested and 
send the patches.

Regards,
Mohan.

> Mohan Kumar M writes:
> 
>> Support for relocatable kdump kernel
> 
> [snip]
> 
>> @@ -1384,7 +1392,15 @@ _STATIC(__after_prom_start)
>>  	/* process relocations for the final address of the kernel */
>>  	lis	r25,PAGE_OFFSET@highest	/* compute virtual base of kernel */
>>  	sldi	r25,r25,32
>> -	mr	r3,r25
>> +#ifdef CONFIG_CRASH_DUMP
>> +	ld	r7,__kdump_flag@got(r2)
>> +	add	r7,r7,r26
>> +	ld	r7,0(r7)
> 
> I think it is dangerous to use an address from the GOT at this point
> when we haven't called relocate() yet.  In fact those 3 instructions
> can be replaced by one:
> 
> 	ld	r7,__kdump_flag-_stext(r26)
> 
> since we have our base address (i.e. the address of _stext) in r26 at
> this point.
> 
>> +#ifdef CONFIG_RELOCATABLE
>> +#ifdef CONFIG_CRASH_DUMP
>> +/*
>> + * Check if the kernel has to be running as relocatable kernel based on the
>> + * variable __kdump_flag, if it is set the kernel is treated as relocatble
>> + * kernel, otherwise it will be moved to PHYSICAL_START
>> + */
>> +	ld	r7,__kdump_flag@got(r2)
>> +	ld	r7,0(r7)
> 
> Here again I would rather you did
> 
> 	ld	r7,__kdump_flag-_stext(r26)
> 
> since the kernel is relocated for its final location by this point,
> but it is not running at the final location yet.
> 
>> +	cmpldi	cr0,r7,1
>> +	bne	regular
>> +
>> +	li	r5,__end_interrupts - _stext	/* just copy interrupts */
>> +	b	5f
>> +regular:
>> +#endif
>> +	lis	r5,(copy_to_here - _stext)@ha
>> +	addi	r5,r5,(copy_to_here - _stext)@l /* # bytes of memory to copy */
>>  
>>  	bl	.copy_and_flush		/* copy the first n bytes	 */
>>  					/* this includes the code being	 */
>> @@ -1411,15 +1443,33 @@ _STATIC(__after_prom_start)
>>  	mtctr	r8
>>  	bctr
>>  
>> +p_end:	.llong	_end - _stext
>> +
>>  4:	/* Now copy the rest of the kernel up to _end */
>>  	addis	r5,r26,(p_end - _stext)@ha
>>  	ld	r5,(p_end - _stext)@l(r5)	/* get _end */
>> -	bl	.copy_and_flush		/* copy the rest */
>> +#else
>> +	lis	r5,(copy_to_here - _stext)@ha
>> +	addi	r5,r5,(copy_to_here - _stext)@l /* # bytes of memory to copy */
>>  
>> -9:	b	.start_here_multiplatform
>> +	bl	.copy_and_flush		/* copy the first n bytes	 */
>> +					/* this includes the code being	 */
>> +					/* executed here.		 */
>> +	addis	r8,r3,(4f - _stext)@ha	/* Jump to the copy of this code */
>> +	addi	r8,r8,(4f - _stext)@l	/* that we just made */
>> +	mtctr	r8
>> +	bctr
>>  
>>  p_end:	.llong	_end - _stext
>>  
>> +4:	/* Now copy the rest of the kernel up to _end */
>> +	addis	r5,r26,(p_end - _stext)@ha
>> +	ld	r5,(p_end - _stext)@l(r5)	/* get _end */
>> +#endif
>> +5:	bl	.copy_and_flush		/* copy the rest */
>> +
>> +9:	b	.start_here_multiplatform
> 
> You have ended up with two separate copies of the code here depending
> on whether or not we have CONFIG_RELOCATABLE set.  I don't think the
> code paths should be different to such an extent.  Please try to make
> the ifdef as small as possible (ideally, nonexistent).
> 
> Paul.
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2008-10-09 16:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-01 18:26 [PATCH] Support for relocatable kdump kernel Mohan Kumar M
2008-10-01 18:26 ` Mohan Kumar M
2008-10-09  5:27 ` Paul Mackerras
2008-10-09  5:27   ` Paul Mackerras
2008-10-09 16:35   ` Mohan Kumar M [this message]
2008-10-09 16:35     ` Mohan Kumar M
  -- strict thread matches above, loose matches on Subject: below --
2008-10-12 23:34 Mohan Kumar M
2008-10-12 23:34 ` Mohan Kumar M
2008-10-13  1:30 ` Paul Mackerras
2008-10-13  1:30   ` Paul Mackerras
2008-10-16 10:33   ` Mohan Kumar M
2008-10-16 10:33     ` Mohan Kumar M
     [not found] <18684.5062.154465.668614@drongo.ozlabs.ibm.com>
2008-10-20  6:43 ` Michael Ellerman
2008-10-20  6:43   ` Michael Ellerman
2008-10-20  9:34   ` Mohan Kumar M
2008-10-20  9:34     ` Mohan Kumar M
2008-10-21  6:03     ` Michael Ellerman
2008-10-21  6:03       ` Michael Ellerman
2008-10-21 18:21       ` Mohan Kumar M
2008-10-21 18:21         ` Mohan Kumar M
2008-10-22  3:38 Michael Ellerman
2008-10-22  4:56 Milton Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48EE32CA.5070401@in.ibm.com \
    --to=mohan@in.ibm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.