From c591d46ee9d2b68ed3ad8f92da59c9f843ad58a4 Mon Sep 17 00:00:00 2001 From: Wojciech Macek Date: Tue, 23 Apr 2019 06:36:32 +0000 Subject: [PATCH] This patch offers a workaround to buf_ring reordering visible on armv7 and armv8. Similar issue to rS302292. Obtained from: Semihalf Authored by: Michal Krawczyk Approved by: wma Differential Revision: https://reviews.freebsd.org/D19932 --- sys/sys/buf_ring.h | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/sys/sys/buf_ring.h b/sys/sys/buf_ring.h index 52c015791cb1..b04b2cb5b81f 100644 --- a/sys/sys/buf_ring.h +++ b/sys/sys/buf_ring.h @@ -310,15 +310,24 @@ buf_ring_peek_clear_sc(struct buf_ring *br) if (!mtx_owned(br->br_lock)) panic("lock not held on single consumer dequeue"); #endif - /* - * I believe it is safe to not have a memory barrier - * here because we control cons and tail is worst case - * a lagging indicator so we worst case we might - * return NULL immediately after a buffer has been enqueued - */ + if (br->br_cons_head == br->br_prod_tail) return (NULL); +#if defined(__arm__) || defined(__aarch64__) + /* + * The barrier is required there on ARM and ARM64 to ensure, that + * br->br_ring[br->br_cons_head] will not be fetched before the above + * condition is checked. + * Without the barrier, it is possible, that buffer will be fetched + * before the enqueue will put mbuf into br, then, in the meantime, the + * enqueue will update the array and the br_prod_tail, and the + * conditional check will be true, so we will return previously fetched + * (and invalid) buffer. + */ + atomic_thread_fence_acq(); +#endif + #ifdef DEBUG_BUFRING /* * Single consumer, i.e. cons_head will not move while we are