d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

This patch offers a workaround to buf_ring reordering

Browse Source 
visible on armv7 and armv8. Similar issue to rS302292.

Obtained from:         Semihalf
Authored by:           Michal Krawczyk <mk@semihalf.com>
Approved by:           wma
Differential Revision: https://reviews.freebsd.org/D19932
This commit is contained in:
Wojciech Macek 2019-04-23 06:36:32 +00:00
parent 4bc523382c
commit c591d46ee9
1 changed files with 15 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
sys/sys/buf_ring.h
View File

@ -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