On 03/27, Kamil Zaripov wrote:
> By "modifies" - do you mean the payload/headers? You can probably use
> the skb pointer address as a unique identifier to connect across
different
> tracepoints?
No, I mean when situations when same package through its way to the
network stack change sk_buff pointer. For example, after skb_clone()
call. I have made some test and found out (empirically) that pointer to
the skb->head a much better tracking ID. However, I am not sure that
there is no other corner cases when skb->head also can change.
Yeah, those are tricky :-(
> Nothing pops to my mind. But I think that if you store skbaddr=dev from
> netif_receive_skb, you should be able to look this up at a later point
> where you know skb->process association?
Yes, I have already implemented and make some test of this approach: I’m
listening at netif_receive_skb tracepoint to create skb_head->netif map
and then listening for __kfree_skb calls to create pid->skb_head map.
However, this approach have some weaknesses:
- Part of packages of TCP protocol packages (ACK, for example) are
handled by the kernel, so I account this packages as kernel activity. But
almost every TCP ACK package have some associated socket, which, in
turn, have associated process.
- I am not sure that all package consumes call __kfree_skb at the end.
Maybe there is some other miscounting in this place.
Maybe there is some other approaches to map packages to processes?
I'm not super familiar with those tracing hooks. Maybe you need to
handle consume_skb as well?
If I were to solve something like this, I'd probably look at cgroup/ingress
hooks. Those are guaranteed to run for every incoming packet into cgroup's
sockets. (at least removes that kfree_skb vs consume_skb issue).
But it doesn't solve your problem with the clones...
