svn commit: r278431 - head/sys/contrib/vchiq/interface/vchiq_arm

[Bruce Evans]

On Mon, 9 Feb 2015, Konstantin Belousov wrote:

> On Mon, Feb 09, 2015 at 05:00:49PM +1100, Bruce Evans wrote:
>> On Mon, 9 Feb 2015, Oleksandr Tymoshenko wrote:
>> ...
>> I think the full bugs only occur when arch has strict alignment
>> requirements and the alignment of the __packed objects is not known.
>> This means that only lesser bugs occur on x86 (unless you enable
>> alignment checking, but this arguably breaks the ABI).  The compiler
>> just generates possibly-misaligned full-width accesses if the arch
>> doesn't have strict alignment requirements.  Often the acceses turn
>> out to be aligned at runtime.  Otherwise, the hardware does them
>> atomically, with a smaller efficiency penalty than split accesses.
>
> On x86 unaligned access is non-atomic.  This was very visible on
> Core2 CPUs where DPCPU code mishandled the alignment, resulting in
> the mutexes from the per-cpu areas breaking badly.
>
> Modern CPUs should not lock several cache lines simultaneously either.

Interesting.  I thought that this was relatively easy to handle in
hardware and required for compatibility, so hardware did it.

This gives a reason other than efficiency to enable alignment checking
so as to find all places that do misaligned accesses.  I last tried this
more than 20 years ago.  Compilers mostly generated aligned accesses.
One exception was for copying small (sub)structs.  Inlining of the copy
assumed maximal alignment or no alignment traps.  Library functions are
more of a problem.  FreeBSD amd64 and i386 memcpy also assume this.
Similarly for the MD mem* in the kernel.  Mostly things are suitably
aligned, so it is the correct optimization to not do extra work to align.

Bruce