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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
