Message-ID: <yw1xipp4cnis.fsf@unicorn.mansr.com>
Date:	Wed, 07 Sep 2011 17:42:19 +0100
From:	Måns Rullgård <mans@...sr.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Catalin Marinas <catalin.marinas@....com>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Dave Martin <dave.martin@...aro.org>,
	John Ogness <john.ogness@...utronix.de>,
	Will Deacon <Will.Deacon@....com>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	"linux-arm-kernel\@lists.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] ARM: alignment: setup alignment handler earlier

Russell King - ARM Linux <linux@....linux.org.uk> writes:

> On Wed, Sep 07, 2011 at 03:40:16PM +0100, Catalin Marinas wrote:
>> On Wed, Sep 07, 2011 at 02:35:04PM +0100, John Ogness wrote:
>> > From 6f3f381800367127dc6430d9b9fa9bd6fc6d8ed0 Mon Sep 17 00:00:00 2001
>> > From: John Ogness <john.ogness@...utronix.de>
>> > 
>> > 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.
>
> Is the problem even solvable?  There are instructions on ARMv6+ which
> always produce an alignment fault (eg, ldrd) irrespective of strict
> alignment checking.

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.

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

The right answer is to not enable strict alignment checking in the first
place.

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

GCC only generates unaligned accesses using instructions which support
this.

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

Indeed, so the sane solution must be to not enable strict checking
anywhere.

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

This is already the case provided the alignment requirements are not
artificially tightened.  What we need is to not enable strict alignment
checking in the kernel as is currently done.

-- 
Måns Rullgård
mans@...sr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists