[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
context.
> 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.
Nicolas
More information about the linux-arm-kernel
mailing list