Re: [PATCH net-next RFC 0/5] ipv6: sr: introduce seg6local End.BPF action

[David Lebrun <dav.lebrun@gmail.com>]

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