Thread (33 messages) 33 messages, 7 authors, 2011-05-27
STALE5542d

[PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

From: catalin.marinas@arm.com (Catalin Marinas)
Date: 2011-05-24 15:26:35

2011/5/24 M?ns Rullg?rd [off-list ref]:
Catalin Marinas [off-list ref] writes:
quoted
On Mon, 2011-05-23 at 14:21 +0100, Russell King - ARM Linux wrote:
quoted
On Mon, May 23, 2011 at 12:16:48PM +0100, Catalin Marinas wrote:
quoted
Newer versions of gcc generate unaligned accesses by default, causing
kernel panics when CONFIG_ALIGNMENT_TRAP is enabled. This patch adds the
-mno-unaligned-access option to gcc.
This description doesn't make sense. ?If we have alignment traps enabled,
then we _expect_ to fix up unaligned loads and stores.

Therefore there should be no panic if CONFIG_ALIGNMENT_TRAP is enabled.

So what's the _actual_ problem that this is trying to address? ?What's
the panic/oops look like? ?And that information should be in the commit
description _anyway_.
Does the patch below look better?

We cannot move alignment_init() earlier as we don't know how early the
compiler would generate unaligned accesses. An alternative is some
#ifdef's in head.S. Please let me know which variant you prefer.
ifdefs may be ugly, but I don't see a better solution here. ?Crippling
the entire build to make a couple of lines slightly more aesthetically
pleasing doesn't seem right to me.
BTW, are we sure that the code generated with unaligned accesses is
better? AFAIK, while processors support unaligned accesses, they may
not always be optimal.

-- 
Catalin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help