Date: Thu, 5 Nov 2009 14:45:05 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Giovanni Trematerra <giovanni.trematerra@gmail.com> Cc: Attilio Rao <attilio@freebsd.org>, des@des.no, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: [PATCH] AMD Opteron Rev. E hack Message-ID: <20091105124505.GT2331@deviant.kiev.zoral.com.ua> In-Reply-To: <4e6cba830911050424y17ea8e7fmf5573b3a765eac27@mail.gmail.com> References: <4e6cba830911050302k56bed35aj5ca9fa16379ab325@mail.gmail.com> <20091105112834.GR2331@deviant.kiev.zoral.com.ua> <4e6cba830911050424y17ea8e7fmf5573b3a765eac27@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--h1wVxq8aeHrvhZJz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 05, 2009 at 01:24:53PM +0100, Giovanni Trematerra wrote: > On Thu, Nov 5, 2009 at 12:28 PM, Kostik Belousov <kostikbel@gmail.com> wr= ote: >=20 > > > > Aren't atomic_readandclear need the same workaround ? > > >=20 > I understood that the bug manifests itself only when lock instruction is = used. > atomic_readandclear doesn't use lock. xchgl uses lock implicitely: If a memory operand is referenced, the processor's locking protocol is automatically implemented for the duration of the exchange operation, regardless of the presence or absence of the LOCK prefix or of the value of the IOPL. > I think i386/linux/linux_support.s and amd64/linux32/linux32_support.s > need the work-around too. What about casuword32 ? It is actually unclear from the bug description whether we need it there. Description states "a locked instruction doesn't act as a read-acquire barrier if followed by a non-locked read-modify-write instruction." casuword32 for amd64, for instance, does movq immediately after cmpxchgl, that is a store op, not read-modify-store. So, does it need a workaround ? Similar stores are performed in linux32_support.s. atomic.h functions definitely need your workaround since they are inlined. Also, I remember that bind(8) provides its own atomic implementation. --h1wVxq8aeHrvhZJz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkryyNEACgkQC3+MBN1Mb4hspgCff9idBrWHCe9mfaMcwdDu6CXR 8dgAn1/b9bcdImR6tghAD8Z3FuipfyVx =Lc6x -----END PGP SIGNATURE----- --h1wVxq8aeHrvhZJz--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091105124505.GT2331>