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

[ Available lists | Index of cvs-all | Month of Jul 2005 | Week of 4 Jul 2005 | Raw email | View thread | Wrap long lines | Reply | Tag ]
From
Robert Watson <rwatson@FreeBSD.org>
Date
4 Jul 2005 10:16:04
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
Message-ID
20050704111844.D2768@fledge.watson.org


[ Hide this part ]
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


Elapsed time: 0.125 seconds