[PATCH 01/14] ARM: bitops: ensure set/clear/change bitops take a word-aligned pointer

Nicolas Pitre nico at fluxnic.net
Tue Jan 18 13:20:52 EST 2011

On Tue, 18 Jan 2011, Russell King - ARM Linux wrote:

> On Tue, Jan 18, 2011 at 01:00:21AM -0500, Nicolas Pitre wrote:
> > I also wonder what happens with a misaligned ldrex/strex... Does the 
> > alignment trap get invoked?  If so, the assertion could be put there 
> > instead if that's not done already, removing this overhead from bitops 
> > calls.  In the pre-ARMv6 case the alignment trap fixup would be applied 
> > as usual since the ldr/str are not special, but the previous code 
> > allowed for misaligned pointer so result would be no worse than before 
> > in that case.  Testing appears to indicate those misaligned bitops are 
> > rather nonexistent so far.
> Well, whether LDREX/STREX always fault for misalignment is well open to
> debate.  The ARM ARM for ARMv7 seems to imply they will always fault for
> misaligned accesses.  For ARMv6, the situation is less clear - the way
> the manual is arranged, it suggests that they will if SCTLR.U is set.
> When it's clear, the ARM ARM doesn't specify what the outcome is.

Probably we should make sure they always fault on both ARMv6 and ARMv7 
regardless of this particular issue.

> I also don't know how our unaligned fixup will behave with an unaligned
> LDREX/STREX without checking the bit patterns.

Making ldrex/strex always fault means that we also need to make the 
alignment fixup code produce a SIGBUS, or panic the kernel if in atomic 

> So... I think that's too many unknowns to rely on it, especially when
> filesystem data is at stake.
> Maybe changing it to:
> 	ands	ip, r1, #3
> 	strneb	r1, [ip]
> instead?

Sure.  That would solve the T2 issue.  Eventually we could revisit the 
need for this assertion here once the above is done.


More information about the linux-arm-kernel mailing list