On 02/07/2019 08:27 AM, Martin Lau wrote: [...] > Following up the discussion in the iovisor conf call. > > One of discussion was about: > other than tw, can __sk_buff->sk always return a > fullsock (PTR_TO_SOCKET_OR_NULL). In request_sock case, > it is doable because it can trace back to the listener sock. > > However, that will go back to the sock_common accessing question. > In particular, how to access the sock_common's fields of the > request_sock itself? Those fields in the request_sock are different > from its listener sock. e.g. the skc_daddr and skc_dport. > > Also, if the sock_common fields of tw is needed, it will become weird > because likely a new "struct bpf_tw_sock" is needed which is OK > but all sock_common fields need to be copied from bpf_sock > to bpf_tw_sock. > > I think reading a sk from a ctx should return the > most basic type PTR_TO_SOCK_COMMON_OR_NULL (unless the running > ctx can guarantee that it always has a fullsock). > Currently, it is __sk_buff->sk. Later, sock_ops->sk...etc. > One single 'struct bpf_sock' and limit fullsock field access > at verification time. The bpf_prog then moves down the chain > based on what it needs. It could be fullsock, tcp_sock...etc. > > I think that will be the most flexible way to write bpf_prog > while also avoid having duplicate fields in different > bpf struct in uapi.
Ok, thanks for following up and sorry for late reply, lets go with sock_common then. What's the plan to moving forward with accessing full sk in case of req sk? Separate helper or backed into the newly added bpf_sk_fullsock() one? Presumably latter? Thanks, Daniel
