From owner-freebsd-current@FreeBSD.ORG Thu Nov 5 14:10:40 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 3A9B6106568B for ; Thu, 5 Nov 2009 14:10:40 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id BBA2C8FC26 for ; Thu, 5 Nov 2009 14:10:39 +0000 (UTC) Received: by bwz5 with SMTP id 5so15627bwz.3 for ; Thu, 05 Nov 2009 06:10:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=g64zbdbVoogsZ2YiNuGF9wpCt/qit8ckhr5A7rfxb0Y=; b=XFsnDrfy0a0/LmfxuLZ/UWRo5fokhQOa9bm7BQsG1Zu18axRY7JrHMHqFQ+WwZT+Dc gdg1ZmkyTMjIvvfIEgf/ZoZwYA55+8N1DAEe68hmpgVyBf+m7wYG6CM3n7miBHQ8Dh+R v/W4UW6CqR+p5exc61EGvbfXNbOKPc+g2y8QY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=tCuLAAv0n12HU1tmTvHlVVj48lADFjvWyb7fpZA3WAv0wX65nMTdjo56Eaj3ADFyfo G+BjVe7pxLCwCdcA/614RQRWiCtSGWbrL8QMBursCnzi8cir26ycHObXzJN3QOL9P/hU X8p1e5NC1d5/aoQGYsfTDgF2iOKHW/Jmglk0o= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.161.215 with SMTP id s23mr420189fax.44.1257430238639; Thu, 05 Nov 2009 06:10:38 -0800 (PST) In-Reply-To: <20091105124505.GT2331@deviant.kiev.zoral.com.ua> References: <4e6cba830911050302k56bed35aj5ca9fa16379ab325@mail.gmail.com> <20091105112834.GR2331@deviant.kiev.zoral.com.ua> <4e6cba830911050424y17ea8e7fmf5573b3a765eac27@mail.gmail.com> <20091105124505.GT2331@deviant.kiev.zoral.com.ua> Date: Thu, 5 Nov 2009 15:10:38 +0100 X-Google-Sender-Auth: d5522211783dd626 Message-ID: <3bbf2fe10911050610p7d3bb0f4kb4446ea651aa7c93@mail.gmail.com> From: Attilio Rao To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Cc: des@des.no, Giovanni Trematerra , 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 14:10:40 -0000 2009/11/5 Kostik Belousov : > On Thu, Nov 05, 2009 at 01:24:53PM +0100, Giovanni Trematerra wrote: >> On Thu, Nov 5, 2009 at 12:28 PM, Kostik Belousov wrote: >> >> > >> > Aren't atomic_readandclear need the same workaround ? >> > >> >> 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. However, that fix is not simple to got as one would think. Our atomics implementation on ia32 and amd64 assume rel/acq barriers aims for the same code but this problem introduces asymmetric behaviour between them. The good way to fix this is to offer an lfence on acq barriers and leave the other cases untouched, but this could be meaning re-structure out atomic.h a lot. I will try to think to a good way to do that when I have more available time. In the while the WARNING msg will do its job (I can still trimm the URL path however). Attilio -- Peace can only be achieved by understanding - A. Einstein