Date: Thu, 1 Oct 2009 15:21:34 +0200 From: Attilio Rao <attilio@freebsd.org> To: Robert Watson <rwatson@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r197643 - in head/sys: kern sys Message-ID: <3bbf2fe10910010621u72d0f692h8f9c4a783667253d@mail.gmail.com> In-Reply-To: <alpine.BSF.2.00.0909301836380.57723@fledge.watson.org> References: <200909301326.n8UDQVB1016396@svn.freebsd.org> <alpine.BSF.2.00.0909301836380.57723@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/9/30 Robert Watson <rwatson@freebsd.org>: > On Wed, 30 Sep 2009, Attilio Rao wrote: > >> When releasing a read/shared lock we need to use a write memory barrier >> in order to avoid, on architectures which doesn't have strong ordered >> writes, CPU instructions reordering. > > Hi Attilio (Fabio, et al), > > Nice catch! Are we aware of specific reported problems that can be laid at > the feet of this bug, or was this more of a "wait a moment, shouldn't there > be a barrier there?". Could you comment on the scope of this problem across > architectures we support? A possible problem related to that would be MD specific and not on ia32/amd64 because there the barriers and simple atomics are the same. Given that sun4v suffers of serveral other problems, that MIPS has no SMP support, you would find it only for arm, ia64 and sparc eventually. Thus I'm not aware of any problem which can be reconducted to that. Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10910010621u72d0f692h8f9c4a783667253d>