Re: Typo in the man7 bpf-helpers page

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux