All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anand Gadiyar <gadiyar@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
	linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org
Subject: Re: [PATCH] ARM: Fix data abort accessing proc_info from __lookup_processor_type (Re: [PATCH 03/10] ARM: hotplug cpu: Keep processor information, startup code & __lookup_processor_type)
Date: Fri, 22 Oct 2010 16:14:33 -0400	[thread overview]
Message-ID: <4CC1F0A9.8050206@ti.com> (raw)
In-Reply-To: <20101022185108.GF17595@atomide.com>

On 10/22/2010 2:51 PM, Tony Lindgren wrote:
> * Russell King - ARM Linux<linux@arm.linux.org.uk>  [101004 10:18]:
>> When hotplug CPU is enabled, we need to keep the list of supported CPUs,
>> their setup functions, and __lookup_processor_type in place so that we
>> can find and initialize secondary CPUs.  Move these into the __CPUINIT
>> section.
>
>> +	__CPUINIT
>> +__lookup_processor_type:
>> +	adr	r3, __lookup_processor_type_data
>> +	ldmia	r3, {r4 - r6}
>> +	sub	r3, r3, r4			@ get offset between virt&phys
>> +	add	r5, r5, r3			@ convert virt addresses to
>> +	add	r6, r6, r3			@ physical address space
>> +1:	ldmia	r5, {r3, r4}			@ value, mask
>> +	and	r4, r4, r9			@ mask wanted bits
>> +	teq	r3, r4
>> +	beq	2f
>> +	add	r5, r5, #PROC_INFO_SZ		@ sizeof(proc_info_list)
>> +	cmp	r5, r6
>> +	blo	1b
>> +	mov	r5, #0				@ unknown processor
>> +2:	mov	pc, lr
>> +ENDPROC(__lookup_processor_type)
>
> The ldmia r5 above can cause a data abort depending on the compiler
> pixies. This can happen if r5 address is unaligned. Here's a fix
> for that.
>
> Regards,
>
> Tony
>
>
> From: Tony Lindgren<tony@atomide.com>
> Date: Thu, 21 Oct 2010 19:00:41 -0700
> Subject: [PATCH] ARM: Fix data abort accessing proc_info from __lookup_processor_type
>
> Commit 5085f3ff458521045f7e43da62b8c30ea7df2e82 added better support for
> CONFIG_HOTPLUG_CPU by keeping proc_info around. However, depending on
> the Kconfig options selected, this can make the booting fail mysteriously
> early on.
>
> Turns out a data abort can happen in __lookup_processor in ldmia r5 {r3, r4}.
> When it happens the address loaded to r5 is not aligned. Fix the problem by
> aligning proc_info.
>
> Reported-by: Anand Gadiyar<gadiyar@ti.com>
> Signed-off-by: Tony Lindgren<tony@atomide.com>

Tested-by: Anand Gadiyar <gadiyar@ti.com>

This patch lets linux-next as of 20101021 boot up on my OMAP4 boards.


>
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index 1953e3d..a58b91d 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -114,6 +114,7 @@ SECTIONS
>   			*(.glue_7)
>   			*(.glue_7t)
>   		*(.got)			/* Global offset table		*/
> +			. = ALIGN(4);
>   			ARM_CPU_KEEP(PROC_INFO)
>   	}
>


WARNING: multiple messages have this Message-ID (diff)
From: gadiyar@ti.com (Anand Gadiyar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: Fix data abort accessing proc_info from __lookup_processor_type (Re: [PATCH 03/10] ARM: hotplug cpu: Keep processor information, startup code & __lookup_processor_type)
Date: Fri, 22 Oct 2010 16:14:33 -0400	[thread overview]
Message-ID: <4CC1F0A9.8050206@ti.com> (raw)
In-Reply-To: <20101022185108.GF17595@atomide.com>

On 10/22/2010 2:51 PM, Tony Lindgren wrote:
> * Russell King - ARM Linux<linux@arm.linux.org.uk>  [101004 10:18]:
>> When hotplug CPU is enabled, we need to keep the list of supported CPUs,
>> their setup functions, and __lookup_processor_type in place so that we
>> can find and initialize secondary CPUs.  Move these into the __CPUINIT
>> section.
>
>> +	__CPUINIT
>> +__lookup_processor_type:
>> +	adr	r3, __lookup_processor_type_data
>> +	ldmia	r3, {r4 - r6}
>> +	sub	r3, r3, r4			@ get offset between virt&phys
>> +	add	r5, r5, r3			@ convert virt addresses to
>> +	add	r6, r6, r3			@ physical address space
>> +1:	ldmia	r5, {r3, r4}			@ value, mask
>> +	and	r4, r4, r9			@ mask wanted bits
>> +	teq	r3, r4
>> +	beq	2f
>> +	add	r5, r5, #PROC_INFO_SZ		@ sizeof(proc_info_list)
>> +	cmp	r5, r6
>> +	blo	1b
>> +	mov	r5, #0				@ unknown processor
>> +2:	mov	pc, lr
>> +ENDPROC(__lookup_processor_type)
>
> The ldmia r5 above can cause a data abort depending on the compiler
> pixies. This can happen if r5 address is unaligned. Here's a fix
> for that.
>
> Regards,
>
> Tony
>
>
> From: Tony Lindgren<tony@atomide.com>
> Date: Thu, 21 Oct 2010 19:00:41 -0700
> Subject: [PATCH] ARM: Fix data abort accessing proc_info from __lookup_processor_type
>
> Commit 5085f3ff458521045f7e43da62b8c30ea7df2e82 added better support for
> CONFIG_HOTPLUG_CPU by keeping proc_info around. However, depending on
> the Kconfig options selected, this can make the booting fail mysteriously
> early on.
>
> Turns out a data abort can happen in __lookup_processor in ldmia r5 {r3, r4}.
> When it happens the address loaded to r5 is not aligned. Fix the problem by
> aligning proc_info.
>
> Reported-by: Anand Gadiyar<gadiyar@ti.com>
> Signed-off-by: Tony Lindgren<tony@atomide.com>

Tested-by: Anand Gadiyar <gadiyar@ti.com>

This patch lets linux-next as of 20101021 boot up on my OMAP4 boards.


>
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index 1953e3d..a58b91d 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -114,6 +114,7 @@ SECTIONS
>   			*(.glue_7)
>   			*(.glue_7t)
>   		*(.got)			/* Global offset table		*/
> +			. = ALIGN(4);
>   			ARM_CPU_KEEP(PROC_INFO)
>   	}
>

  reply	other threads:[~2010-10-22 20:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-04 17:09 [PATCH 03/10] ARM: hotplug cpu: Keep processor information, startup code & __lookup_processor_type Russell King - ARM Linux
2010-10-04 19:25 ` Jeff Ohlstein
2010-10-04 19:30   ` Russell King - ARM Linux
2010-10-22 18:51 ` [PATCH] ARM: Fix data abort accessing proc_info from __lookup_processor_type (Re: [PATCH 03/10] ARM: hotplug cpu: Keep processor information, startup code & __lookup_processor_type) Tony Lindgren
2010-10-22 18:51   ` Tony Lindgren
2010-10-22 20:14   ` Anand Gadiyar [this message]
2010-10-22 20:14     ` Anand Gadiyar
2010-10-23  8:30   ` Russell King - ARM Linux
2010-10-23  8:30     ` Russell King - ARM Linux
2010-10-23 18:18     ` Tony Lindgren
2010-10-23 18:18       ` Tony Lindgren

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=4CC1F0A9.8050206@ti.com \
    --to=gadiyar@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=tony@atomide.com \
    /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.