RE: [EXT] [PATCH net v2] ipv4: ip_gre: Avoid skb_pull() failure in ipgre_xmit()

From: Suman Ghosh
Date: Sun Dec 03 2023 - 10:17:40 EST


>>> }
>>>
>>> if (dev->header_ops) {
>>>+ int pull_len = tunnel->hlen + sizeof(struct iphdr);
>>>+
>>> if (skb_cow_head(skb, 0))
>>> goto free_skb;
>>>
>>> tnl_params = (const struct iphdr *)skb->data;
>>>
>>>- /* Pull skb since ip_tunnel_xmit() needs skb->data pointing
>>>- * to gre header.
>>>- */
>>>- skb_pull(skb, tunnel->hlen + sizeof(struct iphdr));
>>>+ if (!pskb_network_may_pull(skb, pull_len))
>> [Suman] Since this is transmit path, should we add unlikely() here?
>
>Thanks for your comment.
>
>I traced this function and found that pskb_may_pull_reason() seems to
>have appropriate likely() and unlikely() as Eric says.
>
>I'm new to Linux networking. Could you kindly explain the background of
>your suggestion?
>
>I understand that a transmit path must be as fast as possible, so we
>should use unlikely() for rare cases such like this error path. Am I
>correct?
>
>Thanks,
>Shigeru
[Suman] Yes. Likely()/unlikely() helps the compiler for branch prediction and we use it mostly on the data path.
But I cross checked that this is static inline and the function pskb_may_pull() already have likely()/unlikely() in place.
So, you can ignore my comment here.
>
>>>+ goto free_skb;
>>>+
>>>+ /* ip_tunnel_xmit() needs skb->data pointing to gre header. */
>>>+ skb_pull(skb, pull_len);
>>> skb_reset_mac_header(skb);
>>>
>>> if (skb->ip_summed == CHECKSUM_PARTIAL &&
>>>--
>>>2.41.0
>>>
>>