On 04/03/2018 02:40 PM, David Lebrun wrote:
On 04/03/2018 12:16 PM, Mathieu Xhonneux wrote:
In patch 2 I was a bit concerned that:
+ struct seg6_bpf_srh_state *srh_state = (struct
seg6_bpf_srh_state *)
+ &skb->cb;
would not collide with other users of skb->cb, but it seems the way
the hook is placed such usage should always be valid.
Would be good to add a comment describing the situation.
Yes, it's indeed a little hack, but this should be OK since the IPv6
layer does
not use the cb field. Another solution would be to create a new field in
__sk_buff but it's more cumbersome.
I will add a comment.
Good point. The IPv6 layer *does* use the cb field through the IP6CB()
macro. It is first filled in ipv6_rcv() for ingress packets and used,
among others, in the input path by extension headers processing
functions to store EH offsets.
Given that input_action_end_bpf is called in the forwarding path
and terminates with a call to dst_input(), IP6CB() will be then reset by
ipv6_rcv(), and the use of skb->cb here indeed should not collide with
other users.
Actually I'm wrong here. dst_input() will call either ip6_input() or
ip6_forward(), not ipv6_rcv(). Both functions expect IP6CB() to be set,
so using skb->cb here will interfere with them.
What about saving and restoring the IPv6 CB, similarly to what TCP does
with tcp_v6_restore_cb() ?
David
