On Thu, Feb 07, 2019 at 11:21:41PM +0100, Daniel Borkmann wrote: > 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? I will add sk_to_full_sk() to bpf_sk_fullsock() and bpf_tcp_sock().
Thanks, Martin
