From owner-cvs-src@FreeBSD.ORG Mon Jul 4 10:16:04 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 A6D1316A41C; Mon, 4 Jul 2005 10:16:04 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46B5343D46; Mon, 4 Jul 2005 10:16:04 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id C257546B27; Mon, 4 Jul 2005 06:16:03 -0400 (EDT) Date: Mon, 4 Jul 2005 11:20:52 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Peter Grehan In-Reply-To: <42C90A29.2030706@freebsd.org> Message-ID: <20050704111844.D2768@fledge.watson.org> References: <200507022313.j62NDWYC028248@repoman.freebsd.org> <42C90419.8070509@freebsd.org> <20050704105721.Y2768@fledge.watson.org> <42C90A29.2030706@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, Andrew Thompson 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: Mon, 04 Jul 2005 10:16:04 -0000 On Mon, 4 Jul 2005, Peter Grehan wrote: >>> 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. >> >> While it's not immediately relevant to the IP code, generally speaking, >> is it the case that non-aligned integer reads can be non-atomic with >> respect to other CPUs due to the multiple access implementation? > > I'd say certainly ! In fact, are there any architectures that could > guarantee atomicity in this case ? I'd guess not, but couldn't say for sure. The reason it's of interest is that there are a number of places in the kernel where the atomicity of integer and pointer reads is assumed, or order to implement optimistic concurrency or where there are tolerable races. In general, because our compiler works hard to ensure alignment, and because we try to run on architectures that provide hard failure in the presence of an alignment failure, we probably don't have incorrectness as a result of non-atomic non-aligned reads, but it's something to be careful not to introduce, and a case where "hard failure" architectures provide a visible failure where "do it slowly and less atomically" architectures may mask the problem. Robert N M Watson