ring: guarantee load/load order in enqueue and dequeue
ring: guarantee load/load order in enqueue and dequeue

We watched a rte panic of mbuf_autotest in our qualcomm arm64 server
(Amberwing).

Root cause:
In __rte_ring_move_cons_head()
...
        do {
                /* Restore n as it may change every loop */
                n = max;

                *old_head = r->cons.head;                //1st load
                const uint32_t prod_tail = r->prod.tail; //2nd load

In weak memory order architectures (powerpc,arm), the 2nd load might be
reodered before the 1st load, that makes *entries is bigger than we wanted.
This nasty reording messed enque/deque up.

cpu1(producer)          cpu2(consumer)          cpu3(consumer)
                        load r->prod.tail
in enqueue:
load r->cons.tail
load r->prod.head

store r->prod.tail

                                                load r->cons.head
                                                load r->prod.tail
                                                ...
                                                store r->cons.{head,tail}
                        load r->cons.head

Then, r->cons.head will be bigger than prod_tail, then make *entries very
big and the consumer will go forward incorrectly.

After this patch, the old cons.head will be recaculated after failure of
rte_atomic32_cmpset

There is no such issue on X86, because X86 is strong memory order model.
But rte_smp_rmb() doesn't have impact on runtime performance on X86, so
keep the same code without architectures specific concerns.

Fixes: 50d769054872 ("ring: add burst API")
Cc: stable@dpdk.org

Signed-off-by: Jia He <922ed78fdb1e5277ce37cad2a2ddf2a6ab28c673@hxt-semitech.com>
Signed-off-by: Jie Liu <dabec590fbf1be4f0c3003eca33cdce2bb9e3ab2@hxt-semitech.com>
Signed-off-by: Bing Zhao <f18ccb26cb678e9bd16b177d0c1af9a544a6c48a@hxt-semitech.com>
Acked-by: Jerin Jacob <5bca7d2a432bc0f5422b70b2701a4e4fa32edd00@caviumnetworks.com>
Acked-by: Jianbo Liu <ad48e27d4475ec2c10ba93ba465af79f05639344@arm.com>

john-mcnamara-intel/dpdk,john-mcnamara-intel/dpdk,john-mcnamara-intel/dpdk,john-mcnamara-intel/dpdk