From owner-freebsd-arm@FreeBSD.ORG Fri Feb 20 10:23:58 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 2DCC2C08 for ; Fri, 20 Feb 2015 10:23:58 +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 E5B81330 for ; Fri, 20 Feb 2015 10:23:57 +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 t1KANvCI012473 for ; Fri, 20 Feb 2015 10:23:57 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 t1KANvY4012472; Fri, 20 Feb 2015 10:23:57 GMT (envelope-from root) Date: Fri, 20 Feb 2015 10:23:57 +0000 To: freebsd-arm@freebsd.org From: "onwahe-gmail-com (Svatopluk Kraus)" Subject: [Differential] [Changed Subscribers] D1833: Add memory barriers to buf_ring Message-ID: <29d2eb81b1d20447f135855e71450236@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: In-Reply-To: References: Thread-Index: OGRiNDkxY2NmMjRiNTc0MjQ4YTYwNWVkNzIyIFTnCz0= 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: Fri, 20 Feb 2015 10:23:58 -0000 onwahe-gmail-com added a subscriber: onwahe-gmail-com. onwahe-gmail-com added a comment. Hmm, IMHO, this lockless buf ring stuff should be reconsidered much more because of presented issue. It's lockless so there is no way how to get stable snapshot of buf ring variables. A race is always present. Each read value should be considered stale at any moment. Thus what is the real issue here? Is it the order of reading, i.e. prod_tail is pre-read before cons_head? It must be that because in other cases, IMHO, nothing can help. But if it's reordering issue, what else variables are involved? These two reads are very close, but nobody ensures that it could not happen in bigger distance... At least, the same scenario is in buf_ring_advance_sc() and alike in buf_ring_dequeue_mc() and buf_ring_peek(). IMHO, if there is some presumption that some variables are changed in defined order and they should be read in the same order, then we must re-checked the code for all of them. REVISION DETAIL https://reviews.freebsd.org/D1833 To: zbb, imp, kmacy, rpaulo Cc: onwahe-gmail-com, andrew, ian, adrian, freebsd-arm