Re: [PATCH bpf-next 3/8] selftests/bpf: Use bpf_link attachments in test_sockmap

[John Fastabend <john.fastabend@gmail.com>]

Geliang Tang wrote:
> On Mon, 2024-05-27 at 21:36 +0200, Jakub Sitnicki wrote:
> > On Mon, May 27, 2024 at 10:12 AM -07, John Fastabend wrote:
> > > Geliang Tang wrote:
> > > > From: Geliang Tang <tanggeliang@kylinos.cn>
> > > > 
> > > > Switch attachments to bpf_link using
> > > > bpf_program__attach_sockmap() instead
> > > > of bpf_prog_attach().
> > > 
> > > Sorry it took me a few days to get to this.
> > > 
> > > Is there a reason to push this to links vs just leave it as is? I
> > > had
> > > a plan to port all the test_sockmap tests into prog_tests anyways.
> > > I'll
> > > try to push some initial patch next week.
> 
> Great, I strongly agree with porting them into prog_tests. I am also
> willing to participate in implementing this plan together.

I have a first patch that starts to move things I'll dig it up here.
Still a bit behind on everything as you see its Thr already.

> 
> > > 
> > > The one advantage of test_sockmap is we can have it run for longer
> > > runs by pushing different options through so might be worth keeping
> > > just for that.
> > > 
> > > If you really want links here I'm OK with that I guess just asking.
> > 
> > It was me who suggested the switch to bpf_link in reaction to a
> > series
> > of cleanups to prog_type and prog_attach_type submitted by Geliang.
> 
> Yes, patches 3-5 address Jakub's suggestion: switching attachments to
> bpf_link.

OK. Lets just take them the series lgtm. Jakub any other comments?

> 
> > Relevant threads:
> > 
> > https://lore.kernel.org/bpf/9c10d9f974f07fcb354a43a8eca67acb2fafc587.1715926605.git.tanggeliang@kylinos.cn
> > https://lore.kernel.org/bpf/20240522080936.2475833-1-jakub@cloudflare.com
> > https://lore.kernel.org/bpf/e27d7d0c1e0e79b0acd22ac6ad5d8f9f00225303.1716372485.git.tanggeliang@kylinos.cn
> > 
> > I thought bpf_links added more value than cleaning up "old style"
> > attachments.
> 
> Other patches 1-2, 6-8 are small fixes which I found while trying to
> solve the NONBLOCK issue [1]. Yes, I haven't given up on solving this
> issue yet. I think it must be solved, since there is a bug somewhere.
> WDYT?

Yes I think this is an actual issue with the stream parser waking up
sockets before the data is copied into the recv buffers.