cvs commit: src/sys/amd64/include _types.h src/sys/i386/include _types.h src/sys/net if_bridge.c src/sys/netinet ip_var.h src/sys/netinet6 ip6_var.h

[Bruce Evans]

On Tue, 5 Jul 2005, Peter Wemm wrote:

> On Monday 04 July 2005 02:40 am, Peter Grehan wrote:
>>>   Check the alignment of the IP header before passing the packet up
>>> to the packet filter. This would cause a panic on architectures
>>> that require strict alignment such as sparc64 (tier1) and ia64/ppc
>>> (tier2).
>>
>>   FYI, any modern ppc implementation doesn't require strict alignment
>> for integer load/stores though there's a performance penalty for
>> having to split the access into smaller ones.

Anyway, it doesn't follow that it would cause a panic on arches that
require strict alignment, since struct ip is bogusly declared as
__packed so the arches that require strict alignment always split the
load/stores for accesses to it.  Panics only occur when accesses are
made via dubious pointers (e.g., foo(&ipp->ip_src)).  The compiler bug
that the packed attribute is silently cast away makes such accesses too
easy.

> As an aside, I've been contemplating taking a shot at having the AC
> (alignment checking) turned on for the amd64 kernel and see what
> breaks.  But rather than trying to do bit-shifting bcopys etc, I was
> thinking about toggling it off/on around known offenders.

Is this possible?  PSL_AC doesn't do it since it has the same semantics
as on i386's -- it only works when CPL == 3 (user mode in FreeBSD).

> It could be interesting to allow userland to turn it on/off for its own
> use as well.  But I suspect that touching %cr0 on the fly at syscall
> entry/exit could be a serious microcode cost.

It's PSL_AC %rflags.  We already always enable CR0_AM in %cr0.  So userland
has always been able to turn it on/off at some cost and the CR0_AM enable
for it is effectively toggled on entry/exit whether we want it or not
(but at no cost).

Bruce