From owner-freebsd-arm@FreeBSD.ORG Sun Feb 22 01:12:40 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D201671 for ; Sun, 22 Feb 2015 01:12:40 +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 3A7C91D5 for ; Sun, 22 Feb 2015 01:12:40 +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 t1M1CdAX085213 for ; Sun, 22 Feb 2015 01:12:39 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 t1M1CdOY085212; Sun, 22 Feb 2015 01:12:39 GMT (envelope-from root) Date: Sun, 22 Feb 2015 01:12:39 +0000 To: freebsd-arm@freebsd.org From: "kmacy (Kip Macy)" Subject: [Differential] [Commented On] D1833: Add memory barriers to buf_ring Message-ID: <31c66607cc2e8a4ce997fcc05e223550@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: OGRiNDkxY2NmMjRiNTc0MjQ4YTYwNWVkNzIyIFTpLQc= 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: Sun, 22 Feb 2015 01:12:40 -0000 kmacy added a comment. >>! In D1833#26, @meloun-miracle-cz wrote: > > Even I’m not able to evaluate all aspect, I see some serious defects here - at least from ARM point of view. > The buf_ring_enqueue() guarantees proper write ordering (and visibility): > - Store with acquire to br->br_prod_head > - Normal store to br_ring[] > - Store with release to br_prod_tail. > Unfortunately buf_ring_dequeue_sc() have not defined any read ordering and code can see > updated br_prod_tail and stale br_ring[]. (imho, this is true for amd64/i386 too). > Unlike of Semihalf guys, I see little different solution for race in buf_ring_dequeue_sc() read logic. > The br_ring[] must be read after br_prod_tail, but read order of br_cons_head and br_prod_tail is not important. > So (line 183) > > > buf = atomic_load_rel_32(&br->br_ring[cons_head]); > > > looks more correct to me. The update to prod_tail happens _after_ the store to br_ring and is done with an atomic_store_rel_int subsequently in dequeue_sc the read of prod_tail will be done with an atomic_load_acq_int before loading br_prod. Since there is a memory barrier after the update in enqueue and one before the read where is the problem? > > On ARM, all stores to variable referenced by atomic_cmpset() must be done by atomic_store (or by other > atomic_* functions), normal store doesn’t clear exclusive monitor. > Thus, for ARM we **!!MUST!!** use atomic_store() for each store to variable referenced by atomic_cmpset() ! Great, but the only variable that is updated with atomic_cmpset is prod_head to atomically acquire the right to store in to that index in br_ring. Please clarify what the actual problem is. This change fixes the only real issue that I can glean from your comment. REVISION DETAIL https://reviews.freebsd.org/D1833 To: zbb, kmacy, rpaulo, imp Cc: meloun-miracle-cz, onwahe-gmail-com, andrew, ian, adrian, freebsd-arm