Hello Ilya, The processes are created in serial (parent waits for each child to exit). I only use fork() to avoid clean-up code. Sorry for the confusion! Kal On Fri, Oct 18, 2019 at 12:56 AM Ilya Goslhtein <ilejn@xxxxxxxxx> wrote: > > Hello Kal, > > I've noticed that all created processes in your code snippet bound to > the same queue without SHARED flag. > > Is it supposed to work? > > Thanks. > > On 17.10.2019 11:53, Kal Cutter Conley wrote: > > Hello, > > I have managed to extract a reproducer that crashes the kernel. We > > observe the crash with all drivers that support XDP zerocopy (i40e, > > ixgbe, mlx5_core). The program source is attached (C++). Compile with > > a newer clang++ or g++ using flag -std=c++17. It must also be linked > > with libbpf. Use libbpf v0.0.5 and make sure to revert > > 5771dacd3dc2fdd041c51242819a9f212e04af55. > > > > The crash is a kernel NULL pointer dereference in xsk_umem_consume_tx. > > > > Hopefully this is useful, > > Kal > > > > On Wed, Aug 7, 2019 at 10:48 PM Kal Cutter Conley > > <kal.conley@xxxxxxxxxxx> wrote: > >> Hello, > >> I am trying to get AF_XDP working with the i40e driver (Ethernet > >> Controller X710 for 10GbE SFP+). After bind() with XDP_ZEROCOPY the > >> kernel (machine) freezes hard. I have reproduced this on varying > >> kernel versions between 5.1 and 5.3-rc3 with 5.3 kernels freezing > >> also, but at a later stage. I tried replacing my XDP program with a > >> trivial one that simply returns XDP_PASS but it didn't help. On the > >> same system, the xdpsock sample does appear to work with the -z flag, > >> however. Are there any current known issues that could be causing > >> this? I will try to extract a minimal example that exercises the > >> freeze. > >> > >> Thanks, > >> Kal > > -- > Best regards, > Ilya Golshtein >