Date: Fri, 20 Feb 2015 10:23:57 +0000 From: "onwahe-gmail-com (Svatopluk Kraus)" <phabric-noreply@FreeBSD.org> To: freebsd-arm@freebsd.org Subject: [Differential] [Changed Subscribers] D1833: Add memory barriers to buf_ring Message-ID: <29d2eb81b1d20447f135855e71450236@localhost.localdomain> In-Reply-To: <differential-rev-PHID-DREV-ntnotl4wj5wcj2eoukly-req@FreeBSD.org> References: <differential-rev-PHID-DREV-ntnotl4wj5wcj2eoukly-req@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?29d2eb81b1d20447f135855e71450236>