From owner-freebsd-arm@FreeBSD.ORG Tue Feb 24 02:21:00 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECFC4AC6 for ; Tue, 24 Feb 2015 02:21:00 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C9C5579B for ; Tue, 24 Feb 2015 02:21:00 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t1O2L0rk089868 for ; Tue, 24 Feb 2015 02:21:00 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t1O2L0g9089865; Tue, 24 Feb 2015 02:21:00 GMT (envelope-from root) Date: Tue, 24 Feb 2015 02:21:00 +0000 To: freebsd-arm@freebsd.org From: "kmacy (Kip Macy)" Subject: [Differential] [Commented On] D1833: Add memory barriers to buf_ring Message-ID: <2be0f8f73e751b59e35a2d2e802d4379@localhost.localdomain> X-Priority: 3 Thread-Topic: D1833: Add memory barriers to buf_ring X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: OGRiNDkxY2NmMjRiNTc0MjQ4YTYwNWVkNzIyIFTr4Aw= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 02:21:01 -0000 kmacy added a comment. I've been spending more time looking at this than I care to admit. I don't understand why we need the load_acq_32 on prod_tail. The atomic_store_rel_int in enqueue should guarantee that the store to the ring happens before the update to prod_tail. So the consumer should _never_ see a prod_tail that is newer than the ring[prod_next] value. I suspect that something else is going on that we don't understand. REVISION DETAIL https://reviews.freebsd.org/D1833 To: zbb, kmacy, rpaulo, imp Cc: meloun-miracle-cz, onwahe-gmail-com, andrew, ian, adrian, freebsd-arm