ARM: alignment: setup alignment handler earlier

From 6f3f381800367127dc6430d9b9fa9bd6fc6d8ed0 Mon Sep 17 00:00:00 2001
From: John Ogness <[email protected]>

The alignment exception handler is setup fairly late in the boot process (fs_initcall). However, with newer gcc versions and the compiler option -fconserve-stack, code accessing unaligned data is generated in functions that are called earlier, for example pcpu_dump_alloc_info().

This results in unhandled alignment exceptions during boot. By setting up the exception handler sooner, we reduce the window where a compiler may generate code accessing unaligned data.

Quoted 8 lines · John Ogness

From 6f3f381800367127dc6430d9b9fa9bd6fc6d8ed0 Mon Sep 17 00:00:00 2001
From: John Ogness <[email protected]>

The alignment exception handler is setup fairly late in the boot process (fs_initcall). However, with newer gcc versions and the compiler option -fconserve-stack, code accessing unaligned data is generated in functions that are called earlier, for example pcpu_dump_alloc_info().

This is a gcc bug and should not be worked around like this. ?There was another patch[1] to disable -fconserve-stack on ARM due to this broken behaviour. ?This patch was the outcome of a rather lengthy discussion[2].

[1] http://article.gmane.org/gmane.linux.kernel/1148272
[2] http://thread.gmane.org/gmane.linux.ports.arm.kernel/117863

Quoted 4 lines

This results in unhandled alignment exceptions during boot. By setting up the exception handler sooner, we reduce the window where a compiler may generate code accessing unaligned data.

I will also restate my opinion that enabling strict alignment checking on ARMv6 and later is *wrong* in the first place.

From 6f3f381800367127dc6430d9b9fa9bd6fc6d8ed0 Mon Sep 17 00:00:00 2001
From: John Ogness <[email protected]>

The alignment exception handler is setup fairly late in the boot process (fs_initcall). However, with newer gcc versions and the compiler option -fconserve-stack, code accessing unaligned data is generated in functions that are called earlier, for example pcpu_dump_alloc_info(). This results in unhandled alignment exceptions during boot. By setting up the exception handler sooner, we reduce the window where a compiler may generate code accessing unaligned data.

Quoted 12 lines · John Ogness

From 6f3f381800367127dc6430d9b9fa9bd6fc6d8ed0 Mon Sep 17 00:00:00 2001
From: John Ogness <[email protected]>

The alignment exception handler is setup fairly late in the boot process (fs_initcall). However, with newer gcc versions and the compiler option -fconserve-stack, code accessing unaligned data is generated in functions that are called earlier, for example pcpu_dump_alloc_info(). This results in unhandled alignment exceptions during boot. By setting up the exception handler sooner, we reduce the window where a compiler may generate code accessing unaligned data.

While this reduces the window and fixes this particular case, it still doesn't solve the problem. We never know when some unaligned access would be generated for some earlier code.

Quoted 14 lines · Catalin Marinas

Quoted 12 lines · John Ogness

From 6f3f381800367127dc6430d9b9fa9bd6fc6d8ed0 Mon Sep 17 00:00:00 2001
From: John Ogness <[email protected]>

The alignment exception handler is setup fairly late in the boot process (fs_initcall). However, with newer gcc versions and the compiler option -fconserve-stack, code accessing unaligned data is generated in functions that are called earlier, for example pcpu_dump_alloc_info(). This results in unhandled alignment exceptions during boot. By setting up the exception handler sooner, we reduce the window where a compiler may generate code accessing unaligned data.

Quoted 3 lines

While this reduces the window and fixes this particular case, it still doesn't solve the problem. We never know when some unaligned access would be generated for some earlier code.

Is the problem even solvable? There are instructions on ARMv6+ which always produce an alignment fault (eg, ldrd) irrespective of strict alignment checking.

There will always be a window for those - when we don't have the vectors setup - where we potentically could take such a fault and end up crashing. So I'm not sure that the right answer is what's being proposed.

What it's saying to me is that building the kernel in a way that gcc intentionally generates misaligned accesses _will_ bite us in random unknown ways sooner or later.

I don't think its feasible to build some of the kernel with alignment faults enabled and other parts with it disabled - that's going to be very fragile and probably be hell to identify which parts should and should not.

So I think where we're heading is to need gcc _not_ to create any code what so ever which would create a misalignment fault.

There are such instructions (ldrd, ldm), but gcc will not emit those unless the address is known to be aligned. For ARMv6 and later, gcc 4.6 *will* emit potentially unaligned ldr and ldrh since these very clearly allow an unaligned address and are faster than the alternatives in all implementations to date. This is unless strict alignment checking is explicitly enabled, which unfortunately the Linux kernel does for no apparent reason at all.

Quoted 7 lines · M?ns Rullg?rd

There are such instructions (ldrd, ldm), but gcc will not emit those unless the address is known to be aligned. For ARMv6 and later, gcc 4.6 *will* emit potentially unaligned ldr and ldrh since these very clearly allow an unaligned address and are faster than the alternatives in all implementations to date. This is unless strict alignment checking is explicitly enabled, which unfortunately the Linux kernel does for no apparent reason at all.

"no apparant reason at all" heh. The reason is to keep the code simple and free from bugs. To do otherwise means that each of the CPU files needs to be littered with ifdefs to deal with the alignment fault configuration, of which there are 16 of them (ignoring v6 and v7.)

If you think code maintanence of the same thing in 16 places is efficient then I guess there is "no apparant reason". I beg to differ, being one of those folk who have had to edit 18 different places several times.

So no, I do not intend to move this:

#ifdef CONFIG_ALIGNMENT_TRAP
        orr     r0, r0, #CR_A
#else
        bic     r0, r0, #CR_A

#endif

into 16 separate places in the kernel.

Quoted 7 lines · M?ns Rullg?rd

There are such instructions (ldrd, ldm), but gcc will not emit those unless the address is known to be aligned. For ARMv6 and later, gcc 4.6 *will* emit potentially unaligned ldr and ldrh since these very clearly allow an unaligned address and are faster than the alternatives in all implementations to date. This is unless strict alignment checking is explicitly enabled, which unfortunately the Linux kernel does for no apparent reason at all.

"no apparant reason at all" heh. The reason is to keep the code simple and free from bugs.

To do otherwise means that each of the CPU files needs to be littered with ifdefs to deal with the alignment fault configuration, of which there are 16 of them (ignoring v6 and v7.)

If you think code maintanence of the same thing in 16 places is efficient then I guess there is "no apparant reason". I beg to differ, being one of those folk who have had to edit 18 different places several times.

So no, I do not intend to move this:

#ifdef CONFIG_ALIGNMENT_TRAP
        orr     r0, r0, #CR_A
#else
        bic     r0, r0, #CR_A

#endif

into 16 separate places in the kernel.

Quoted 14 lines · Catalin Marinas

Quoted 12 lines · John Ogness

From 6f3f381800367127dc6430d9b9fa9bd6fc6d8ed0 Mon Sep 17 00:00:00 2001
From: John Ogness <[email protected]>

The alignment exception handler is setup fairly late in the boot process (fs_initcall). However, with newer gcc versions and the compiler option -fconserve-stack, code accessing unaligned data is generated in functions that are called earlier, for example pcpu_dump_alloc_info(). This results in unhandled alignment exceptions during boot. By setting up the exception handler sooner, we reduce the window where a compiler may generate code accessing unaligned data.

Quoted 3 lines

While this reduces the window and fixes this particular case, it still doesn't solve the problem. We never know when some unaligned access would be generated for some earlier code.

Is the problem even solvable? ?There are instructions on ARMv6+ which always produce an alignment fault (eg, ldrd) irrespective of strict alignment checking.