Merge branch 'bpf-add-bpf_link-support-for-sk_msg-and-sk_skb-progs'
Yonghong Song says: ==================== bpf: Add bpf_link support for sk_msg and sk_skb progs One of our internal services started to use sk_msg program and currently it used existing prog attach/detach2 as demonstrated in selftests. But attach/detach of all other bpf programs are based on bpf_link. Consistent attach/detach APIs for all programs will make things easy to undersand and less error prone. So this patch added bpf_link support for BPF_PROG_TYPE_SK_MSG. Based on comments from previous RFC patch, I added BPF_PROG_TYPE_SK_SKB support as well as both program types have similar treatment w.r.t. bpf_link handling. For the patch series, patch 1 added kernel support. Patch 2 added libbpf support. Patch 3 added bpftool support and patches 4/5 added some new tests. Changelogs: v6 -> v7: - fix an missing-mutex_unlock error. v5 -> v6: - resolve libbpf conflict due to recent upstream change. - add a bpf_link_create() test. - some code refactoring for better code quality. v4 -> v5: - increase scope of mutex protection in link_release. - remove previous-leftover entry in libbpf.map. - make some code changes for better understanding. v3 -> v4: - use a single mutex lock to protect both attach/detach/update and release/fill_info/show_fdinfo. - simplify code for sock_map_link_lookup(). - fix a few bugs. - add more tests. v2 -> v3: - consolidate link types of sk_msg and sk_skb to a single link type BPF_PROG_TYPE_SOCKMAP. - fix bpf_link lifecycle issue. in v2, after bpf_link is attached, a subsequent prog_attach could change that bpf_link. this patch makes bpf_link having correct behavior such that it won't go away facing other prog/link attach for the same map and the same attach type. ==================== Link: https://lore.kernel.org/r/20240410043522.3736912-1-yonghong.song@linux.devSigned-off-by: Alexei Starovoitov <ast@kernel.org>
Showing
Please register or sign in to comment