Re: [PATCH v2 net-next 0/3] bpf: share helpers between tracing and networking

[Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>]

On 6/16/15 2:19 AM, Daniel Borkmann wrote:
> if you really want to, you
> could go via skb->sk->sk_socket->file and then retrieve credentials
> from there for egress side (you can have a look at xt_owner). You'd
> need a different *_proto helper for tc in that case, which would
> then map to BPF_FUNC_get_current_uid_gid, etc. But that doesn't work
> for ingress however, even if you would have early demux, so you
> would need to let the eBPF helper function return an error code in
> that case.

was looking at cls_flow to do exactly that, but with different helper
name. Like bpf_get_socket_uid_gid(). The use case is to collect
network statistics per-user and per-process. I think android still using
some out of tree hacks for that. Ingress indeed is not solved by this
skb->sk->sk_socket approach. I considered kprobe style, but accessing
skb->len via probe_read is kernel specific, nonportable and slow-ish.
Ideally we would allow a blend of tracing and networking programs,
then the best solution would be one or two stable tracepoints in
networking stack where skb is visible and receiving/transmitting task
is also visible, then skb->len and task->pid together would give nice
foundation for accurate stats.