From owner-freebsd-current@FreeBSD.ORG Thu Nov 5 12:45:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38DE9106568D; Thu, 5 Nov 2009 12:45:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 85B9B8FC16; Thu, 5 Nov 2009 12:45:11 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id nA5Cj6hi059969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2009 14:45:06 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id nA5Cj6WI052781; Thu, 5 Nov 2009 14:45:06 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id nA5Cj508052780; Thu, 5 Nov 2009 14:45:05 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 5 Nov 2009 14:45:05 +0200 From: Kostik Belousov To: Giovanni Trematerra Message-ID: <20091105124505.GT2331@deviant.kiev.zoral.com.ua> References: <4e6cba830911050302k56bed35aj5ca9fa16379ab325@mail.gmail.com> <20091105112834.GR2331@deviant.kiev.zoral.com.ua> <4e6cba830911050424y17ea8e7fmf5573b3a765eac27@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h1wVxq8aeHrvhZJz" Content-Disposition: inline In-Reply-To: <4e6cba830911050424y17ea8e7fmf5573b3a765eac27@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Attilio Rao , des@des.no, FreeBSD Current Subject: Re: [PATCH] AMD Opteron Rev. E hack X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 12:45:12 -0000 --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 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--