Re: [PATCHv3 net] bonding: fix ICMPv6 header handling when receiving IPv6 messages

[Jay Vosburgh <jay.vosburgh@canonical.com>]

Hangbin Liu <liuhangbin@gmail.com> wrote:

>On Wed, Nov 09, 2022 at 01:48:11PM -0800, Eric Dumazet wrote:
>> On Wed, Nov 9, 2022 at 1:23 PM Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
>> >
>> > Eric Dumazet <edumazet@google.com> wrote:
>> > >Quite frankly I would simply use
>> > >
>> > >if (pskb_may_pull(skb, sizeof(struct ipv6hdr) + sizeof(struct icmp6hdr))
>> > > instead of  skb_header_pointer()
>> > >because chances are high we will need the whole thing in skb->head later.
>> >
>> >         Well, it was set up this way with skb_header_pointer() instead
>> > of pskb_may_pull() by you in de063b7040dc ("bonding: remove packet
>> > cloning in recv_probe()") so the bonding rx_handler wouldn't change or
>> > clone the skb.  Now, I'm not sure if we should follow your advice to go
>> > against your advice.
>> 
>> Ah... I forgot about this, thanks for reminding me it ;)
>
>Hi David,
>
>The patch state[1] is Changes Requested, but I think Eric has no object on this
>patch now. Should I keep waiting, or re-send the patch?
>
>[1] https://patchwork.kernel.org/project/netdevbpf/patch/20221109014018.312181-1-liuhangbin@gmail.com/

	The excerpt above is confirming that using skb_header_pointer()
is the correct implementation to use.

	However, the patch needs to change to call skb_header_pointer()
sooner, to insure that the IPv6 header is available.  I've copied the
relevant part of the discussion below:

>>   	struct slave *curr_active_slave, *curr_arp_slave;
>> -	struct icmp6hdr *hdr = icmp6_hdr(skb);
>>   	struct in6_addr *saddr, *daddr;
>> +	const struct icmp6hdr *hdr;
>> +	struct icmp6hdr _hdr;
>>     	if (skb->pkt_type == PACKET_OTHERHOST ||
>>   	    skb->pkt_type == PACKET_LOOPBACK ||
>> -	    hdr->icmp6_type != NDISC_NEIGHBOUR_ADVERTISEMENT)
>> +	    ipv6_hdr(skb)->nexthdr != NEXTHDR_ICMP)
>
>
>What makes sure IPv6 header is in skb->head (linear part of the skb) ?

	The above comment is from Eric.  I had also mentioned that this
particular problem already existed in the code being patched.

	-J

---
	-Jay Vosburgh, jay.vosburgh@canonical.com