On Tue, Apr 23, 2019 at 06:36:32AM +0000, Wojciech Macek wrote:
> Author: wma
> Date: Tue Apr 23 06:36:32 2019
> New Revision: 346593
> URL: https://svnweb.freebsd.org/changeset/base/346593
> 
> Log:
>   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 <m...@semihalf.com>
>   Approved by:           wma
>   Differential Revision: https://reviews.freebsd.org/D19932
> 
> Modified:
>   head/sys/sys/buf_ring.h
> 
> Modified: head/sys/sys/buf_ring.h
> ==============================================================================
> --- head/sys/sys/buf_ring.h   Tue Apr 23 04:06:26 2019        (r346592)
> +++ head/sys/sys/buf_ring.h   Tue Apr 23 06:36:32 2019        (r346593)
> @@ -310,14 +310,23 @@ 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

Why is it specific to ARM?
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Reply via email to