Re: [patch net-next] net: hns: add skb_reset_mac_header() after skb being alloc

From: Yisen Zhuang
Date: Mon Jun 20 2016 - 03:13:13 EST




å 2016/6/15 18:30, Yisen Zhuang åé:
> Hi David,
>
> Thanks for your suggestions.
>
> Please see my comments below.
>
> Thanks,
>
> Yisen
>
> å 2016/6/15 13:41, David Miller åé:
>> From: Yisen Zhuang <Yisen.Zhuang@xxxxxxxxxx>
>> Date: Mon, 13 Jun 2016 20:41:22 +0800
>>
>>> From: Kejian Yan <yankejian@xxxxxxxxxx>
>>>
>>> HNS receives a packet without doing anything, but it should call
>>> skb_reset_mac_header() to initialize the header before using
>>> eth_hdr().
>>>
>>> Fixes: 0d6b425a3773c3445b0f51b2f333821beaacb619
>>> Signed-off-by: Kejian Yan <yankejian@xxxxxxxxxx>
>>> Signed-off-by: Yisen Zhuang <Yisen.Zhuang@xxxxxxxxxx>
>>
>> Well, this patch made me look at this function.
>>
>> You really shouldn't be filtering packets looped back, that is
>> the stack's job. It shouldn't be happening in the driver.
>
> If we use ping6 to test if it is connected to network, CPUs would send out the NS packets
> and these packets will be looped back to CPUs. If driver does not drop these packets,
> they will be sent to protocol stack and protocol stack consider that there is a device
> with the same address and it is not available address. It will show us the log like
> "connect: Cannot assign requested address". Then it can not connect to the network enviroment.
> Thus, we drop these packets looped back in HNS driver.
>

Hi David,

What is the opinion about this issue? We need this patch to resolve the issue.

Hoping for your suggestions.

Many thanks,

Yisen

>>
>> And once you remove that code, this patch here is no longer
>> necessary.
>>
>> Second of all, unless you card supports every protocol that
>> exists in the past, present, and _future_ you cannot set
>> skb->ip_summed to CHECKSUM_UNNECSSARY unconditionally like
>> that.
>>
>> You can only set that for protocols your chip actually supports.
>
> Thanks for your suggestions. I will prepare a new patch to fix it.
>
>>
>> .
>>
>
> _______________________________________________
> linuxarm mailing list
> linuxarm@xxxxxxxxxx
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>