Date: Fri, 20 Feb 2015 22:44:18 +0000 From: "kmacy (Kip Macy)" <phabric-noreply@FreeBSD.org> To: freebsd-arm@freebsd.org Subject: [Differential] [Commented On] D1833: Add memory barriers to buf_ring Message-ID: <48fbdaded4fa374364397ab9e8f9a4bf@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
kmacy added a comment. >>! In D1833#18, @onwahe-gmail-com wrote: > 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. Getting the memory ordering correct is difficult, yes. But the semantics are not ambiguous. Consumers are (at least for the most part) using it correctly in the network stack. REVISION DETAIL https://reviews.freebsd.org/D1833 To: zbb, imp, rpaulo, kmacy 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?48fbdaded4fa374364397ab9e8f9a4bf>