On 02.10.2020 10:46, Eric Dumazet wrote:
> On Fri, Oct 2, 2020 at 10:32 AM Eric Dumazet <eric.duma...@gmail.com> wrote:
>>
>>
>>
>> On 10/2/20 10:26 AM, Eric Dumazet wrote:
>>> On Thu, Oct 1, 2020 at 10:34 PM Heiner Kallweit <hkallwe...@gmail.com>
>>> wrote:
>>>>
>>>> I have a problem with the following code in ndo_start_xmit() of
>>>> the r8169 driver. A user reported the WARN being triggered due
>>>> to gso_size > 0 and gso_type = 0. The chip supports TSO(6).
>>>> The driver is widely used, therefore I'd expect much more such
>>>> reports if it should be a common problem. Not sure what's special.
>>>> My primary question: Is it a valid use case that gso_size is
>>>> greater than 0, and no SKB_GSO_ flag is set?
>>>> Any hint would be appreciated.
>>>>
>>>>
>>>
>>> Maybe this is not a TCP packet ? But in this case GSO should have taken
>>> place.
>>>
>>> You might add a
>>> pr_err_once("gso_type=%x\n", shinfo->gso_type);
>>>
>
>>
>> Ah, sorry I see you already printed gso_type
>>
>> Must then be a bug somewhere :/
>
>
> napi_reuse_skb() does :
>
> skb_shinfo(skb)->gso_type = 0;
>
> It does _not_ clear gso_size.
>
> I wonder if in some cases we could reuse an skb while gso_size is not zero.
>
> Normally, we set it only from dev_gro_receive() when the skb is queued
> into GRO engine (status being GRO_HELD)
>
Thanks Eric. I'm no expert that deep in the network stack and just wonder
why napi_reuse_skb() re-initializes less fields in shinfo than __alloc_skb().
The latter one does a
memset(shinfo, 0, offsetof(struct skb_shared_info, dataref));
What I can do is letting the affected user test the following.
diff --git a/net/core/dev.c b/net/core/dev.c
index 62b06523b..8e75399cc 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6088,6 +6088,7 @@ static void napi_reuse_skb(struct napi_struct *napi,
struct sk_buff *skb)
skb->encapsulation = 0;
skb_shinfo(skb)->gso_type = 0;
+ skb_shinfo(skb)->gso_size = 0;
skb->truesize = SKB_TRUESIZE(skb_end_offset(skb));
skb_ext_reset(skb);
--
2.28.0
