John Fastabend wrote: > Andrii Nakryiko wrote: > > On Wed, Nov 17, 2021 at 10:00 AM John Fastabend > > <john.fastabend@xxxxxxxxx> wrote: > > > > > > Andrii Nakryiko wrote: > > > > On Sun, Nov 14, 2021 at 9:21 PM John Fastabend <john.fastabend@xxxxxxxxx> wrote: > > > > > > > > > > Alexei Starovoitov wrote: > > > > > > test_maps is failing in bpf tree: > > > > > > > > > > > > $ ./test_maps > > > > > > Failed sockmap recv > > > > > > > > > > > > and causing BPF CI to stay red. > > > > > > > > > > > > Since bpf-next is fine, I suspect it is one of John's or Jussi's patches. > > > > > > > > > > > > Please take a look. > > > > > > > > > > I'll look into it thanks. > > > > > > > > Any updates, John? Should we just disable test_maps in CI to make it > > > > useful again? > > > > > > I'm debugging this now. Hopefully I'll have a fix shortly (today I hope). > > > Maybe, it makes sense to wait for EOD and if I still don't have the fix > > > disable it then. Anyways fixing it is top of list now. > > > > Sounds good, let's hope you find it and fix it today. > > OK got the fix, but its fairly subtle. Whats happening is when socks are > removed from a map their programs are not actually being removed. They > continue to live with the sock for the lifetime of the socket or until > the last reference held from BPF side is lost. At which point all progs > are dropped and socket returns to normal/preBPF state. We never noticed > it on our real use cases because once we move sockets into BPF we never > release them until the socket is free. The fix is to null the set progs > and then do the update_sk_prot call which will decide based on the > configured programs what proto ops need to be set to. Fix posted here, https://lore.kernel.org/bpf/20211119181418.353932-1-john.fastabend@xxxxxxxxx/ Thanks, John
