All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
	"Gadiyar, Anand" <gadiyar@ti.com>
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 11:51:08 -0700	[thread overview]
Message-ID: <20101022185108.GF17595@atomide.com> (raw)
In-Reply-To: <E1P2oXV-00020M-QV@rmk-PC.arm.linux.org.uk>

* 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>

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: tony@atomide.com (Tony Lindgren)
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 11:51:08 -0700	[thread overview]
Message-ID: <20101022185108.GF17595@atomide.com> (raw)
In-Reply-To: <E1P2oXV-00020M-QV@rmk-PC.arm.linux.org.uk>

* 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>

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)
 	}
 

  parent reply	other threads:[~2010-10-22 18:51 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 ` Tony Lindgren [this message]
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 20:14   ` Anand Gadiyar
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=20101022185108.GF17595@atomide.com \
    --to=tony@atomide.com \
    --cc=gadiyar@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    /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.