My bad! > No, I don't think there is anything wrong with that. I suppose you mean bpf_get_socket_cookie_sock_(ad dr|ops) (the functions you mentioned don't exist), but the four variants of the helper just have the same name, and take different objects for their context. Yes! I made a mistake in the function names in the first email. Thank you for pointing that out. I am an eBPF newbie and I am learning it currently. AFAIK, language C doesn't support function overriding via different parameters. So how do these four functions co-exist? Some naive search in the kernel code leads me to: https://elixir.bootlin.com/linux/v6.2-rc6/source/net/core/filter.c#L4919 ``` static const struct bpf_func_proto bpf_get_socket_cookie_sock_addr_proto = { .func = bpf_get_socket_cookie_sock_addr, .gpl_only = false, .ret_type = RET_INTEGER, .arg1_type = ARG_PTR_TO_CTX, }; ``` https://elixir.bootlin.com/linux/v6.2-rc6/source/net/core/filter.c#L4955 ``` static const struct bpf_func_proto bpf_get_socket_cookie_sock_ops_proto = { .func = bpf_get_socket_cookie_sock_ops, .gpl_only = false, .ret_type = RET_INTEGER, .arg1_type = ARG_PTR_TO_CTX, }; ``` It seems that the function definitions are quite real... Quentin Monnet <quentin@xxxxxxxxxxxxx> 于2023年1月31日周二 20:02写道： > > 2023-01-31 12:40 UTC+0100 ~ Alejandro Colomar <alx.manpages@xxxxxxxxx> > > [Resend with Quentin's right address, I hope] > > > > Hi Zexuan, Quentin, > > > > On 1/31/23 11:03, Zexuan Luo wrote: > >> Hello Colomar, > >> > >> I just found a potential bug in the bpf-helpers page. > > > > Thanks for reporting bugs :) > > > >> > >> Under the https://www.man7.org/linux/man-pages/man7/bpf-helpers.7.html: > > > > This page is generated from the Linux kernel sources. I've CCed Quentin > > and the BPF list so they can check it there. > > > > Hi Alejandro, Zexuan, > Thanks for the report! Happy to take fixes, however, see below... > > > BTW, I'm refreshing the page now. > > > > Great, thank you! > > > Quentin, I realized in the diff that there is some inconsistency in the > > number of spaces after a sentence-ending period. Could you please use > > two spaces for that? It's especially important for groff(1), which will > > render it differently. However, it's not a big issue, so don't feel > > urged to do that. > > Yes, you mentioned that in the past and this is on my list. As you can > see, I haven't felt urged so far indeed :). But it's still on my mind > for the next time I take a look at this doc for typos etc. > > > > > Cheers, > > > > Alex > > > >> > >> ``` > >> u64 bpf_get_socket_cookie(struct sk_buff *skb) > >> > >> Description > >> If the struct sk_buff pointed by skb has a known > >> socket, retrieve the cookie (generated by the > >> kernel) of this socket. If no cookie has been set > >> yet, generate a new cookie. Once generated, the > >> socket cookie remains stable for the life of the > >> socket. This helper can be useful for monitoring > >> per socket networking traffic statistics as it > >> provides a global socket identifier that can be > >> assumed unique. > >> > >> Return A 8-byte long non-decreasing number on success, or > >> 0 if the socket field is missing inside skb. > >> > >> u64 bpf_get_socket_cookie(struct bpf_sock_addr *ctx) > >> > >> Description > >> Equivalent to bpf_get_socket_cookie() helper that > >> accepts skb, but gets socket from struct > >> bpf_sock_addr context. > >> > >> Return A 8-byte long non-decreasing number. > >> > >> u64 bpf_get_socket_cookie(struct bpf_sock_ops *ctx) > >> > >> Description > >> Equivalent to bpf_get_socket_cookie() helper that > >> accepts skb, but gets socket from struct > >> bpf_sock_ops context. > >> > >> Return A 8-byte long non-decreasing number. > >> ``` > >> > >> The function bpf_get_socket_cookie repeats three times. The second one > >> should be bpf_get_socket_cookie_addr and the third one should be > >> bpf_get_socket_cookie_ops. > > > > No, I don't think there is anything wrong with that. I suppose you mean > bpf_get_socket_cookie_sock_(addr|ops) (the functions you mentioned don't > exist), but the four variants of the helper just have the same name, and > take different objects for their context. There is no risk of collision > because they are each associated to distinct eBPF program types. > > Please see also commit d692f1138a4b ("bpf: Support bpf_get_socket_cookie > in more prog types"): "It doesn't introduce new helpers. Instead it > reuses same helper name bpf_get_socket_cookie() but adds support to this > helper to accept `struct bpf_sock_addr` and `struct bpf_sock_ops`.". > > Thanks, > Quentin
