[Bug 1107] [22.11-rc1][meson test] seqlock_autotest test failed

[Mattias Rönnblom]

On 2022-10-18 07:57, bugzilla at dpdk.org wrote:
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-77db8b1c577f1119&q=1&e=8bb9cf17-6273-48ca-96b9-52e8c1287ae2&u=https%3A%2F%2Fbugs.dpdk.org%2Fshow_bug.cgi%3Fid%3D1107
> 
>              Bug ID: 1107
>             Summary: [22.11-rc1][meson test] seqlock_autotest test failed
>             Product: DPDK
>             Version: 22.11
>            Hardware: All
>                  OS: All
>              Status: UNCONFIRMED
>            Severity: normal
>            Priority: Normal
>           Component: meson
>            Assignee: dev at dpdk.org
>            Reporter: yux.jiang at intel.com
>    Target Milestone: ---
> 
> [Environment]
> DPDK version: dpdk22.11.0rc1 a74b1b25136a592c275afbfa6b70771469750aee
> OS: CentOS7.9/3.10.0-1160.62.1.el7.x86_64 or 3.10.0-1160.71.1.el7.x86_64
> Compiler: gcc version 4.8.5 20150623

Have you tried with a different compiler? Preferably one supported by 
DPDK, unlike 4.8.5.

Some versions of GCC had problems with C11 release-type thread fences. 
GCC 7.2, for example, could reorder non-atomic stores across the fence. 
(That mightily confused me, when I came across this in my very first 
program using C11-style atomics.)

It might be worth disassembling the code to make sure that didn't happen 
in your case.

Also, you could try to replace the release barrier and/or the acquire 
barrier with a rte_compiler_barrier(), just to see if this problem is 
indeed related to the barriers. On a TSO machine, a compiler barrier 
should do the job. Or you use __sync_synchronize(). (Just for 
exploration, not as a bug fix or workaround.)

> Hardware platform: Intel(R) Atom(TM) CPU C3758 @ 2.20GHz
> 
> 
> [Test Setup]
> Steps to reproduce
> 1. Use the following command to build DPDK:
> CC=gcc meson -Denable_kmods=True -Dlibdir=lib --default-library=static
> x86_64-native-linuxapp-gcc/
> ninja -C x86_64-native-linuxapp-gcc/
> 
> 2. Execute the following command in the dpdk directory.
> meson test -C x86_64-native-bsdapp-gcc/ seqlock_autotest
> 
> [Show the output from the previous commands]
> 2/2 DPDK:fast-tests / seqlock_autotest      FAIL             2.51s   (exit
> status 255 or signal 127 SIGinvalid)
> 04:23:38 MALLOC_PERTURB_=139 DPDK_TEST=seqlock_autotest
> /root/dpdk/x86_64-native-linuxapp-gcc/app/test/dpdk-test
> --file-prefix=seqlock_autotest
> ----------------------------------- output -----------------------------------
> stdout:
> RTE>>seqlock_autotest^M
> Reader observed inconsistent data values 10856068477537484964
> 9973142773974991064 9973142773974991064
> Test Failed
> RTE>>
> stderr:
> EAL: Detected CPU lcores: 8
> EAL: Detected NUMA nodes: 1
> EAL: Detected static linkage of DPDK
> EAL: Multi-process socket /var/run/dpdk/seqlock_autotest/mp_socket
> EAL: Selected IOVA mode 'VA'
> EAL: 1024 hugepages of size 2097152 reserved, but no mounted hugetlbfs found
> for that size
> APP: HPET is not enabled, using TSC as default timer
> 
> [Expected Result]
> Test ok.
>