From owner-cvs-src@FreeBSD.ORG Tue Jul 5 19:08:11 2005 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AAC516A41C; Tue, 5 Jul 2005 19:08:04 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00BFC4425E; Tue, 5 Jul 2005 18:58:44 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j65IwYj3017244; Wed, 6 Jul 2005 04:58:34 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j65IwWop025002; Wed, 6 Jul 2005 04:58:33 +1000 Date: Wed, 6 Jul 2005 04:58:33 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Peter Wemm In-Reply-To: <200507051053.37195.peter@wemm.org> Message-ID: <20050706044025.I64745@delplex.bde.org> References: <200507022313.j62NDWYC028248@repoman.freebsd.org> <42C90419.8070509@freebsd.org> <200507051053.37195.peter@wemm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@freebsd.org, cvs-all@freebsd.org, src-committers@freebsd.org, Andrew Thompson , Peter Grehan Subject: Re: 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 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2005 19:08:11 -0000 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