W dniu 16.11.2018 o 21:06, Cong Wang pisze:
On Thu, Nov 15, 2018 at 8:50 PM Herbert Xu wrote:
On Thu, Nov 15, 2018 at 06:23:38PM -0800, Cong Wang wrote:
Normally if the hardware's partial checksum is valid then we just
trust it and send the packet along. However, if the partial
checksum is
On Tue, Nov 20, 2018 at 10:18:17AM -0800, Eric Dumazet wrote:
>
> > Something like this? Is it safe to linearize here?
It looks safe to me. It's only unsafe if your skb is shared which
from my grepping does not appear to be the case (and it cannot be
shared if you're modifying skb->csum which al
On Tue, Nov 20, 2018 at 10:13 AM David Miller wrote:
>
> From: Eric Dumazet
> Date: Mon, 19 Nov 2018 17:47:33 -0800
>
> >
> >
> > On 11/19/2018 05:42 PM, Cong Wang wrote:
> >> On Fri, Nov 16, 2018 at 12:15 PM Cong Wang
> >> wrote:
> >>>
> >>> On Thu, Nov 15, 2018 at 8:52 PM Eric Dumazet
> >>>
From: Eric Dumazet
Date: Mon, 19 Nov 2018 17:47:33 -0800
>
>
> On 11/19/2018 05:42 PM, Cong Wang wrote:
>> On Fri, Nov 16, 2018 at 12:15 PM Cong Wang wrote:
>>>
>>> On Thu, Nov 15, 2018 at 8:52 PM Eric Dumazet wrote:
You could use trafgen to cook such a frame and confirm the theory.
On Mon, Nov 19, 2018 at 11:25:47AM -0800, Cong Wang wrote:
>
> Hmm, it calls csum_tcpudp_magic() directly instead of
> __skb_checksum_validate_complete(), but it also sets ip_summed
> to CHECKSUM_UNNECESSARY:
>
> 20 if ((protocol == 0 && !csum_fold(skb->csum)) ||
> 21
On 11/19/2018 05:42 PM, Cong Wang wrote:
> On Fri, Nov 16, 2018 at 12:15 PM Cong Wang wrote:
>>
>> On Thu, Nov 15, 2018 at 8:52 PM Eric Dumazet wrote:
>>>
>>> You could use trafgen to cook such a frame and confirm the theory.
>>>
>>> Something like :
>>
>> I will try it.
>
> I just tried it,
On Fri, Nov 16, 2018 at 12:15 PM Cong Wang wrote:
>
> On Thu, Nov 15, 2018 at 8:52 PM Eric Dumazet wrote:
> >
> > You could use trafgen to cook such a frame and confirm the theory.
> >
> > Something like :
>
> I will try it.
I just tried it, it doesn't make much difference, the warning only
show
On Sun, Nov 18, 2018 at 8:02 PM Herbert Xu wrote:
>
> On Fri, Nov 16, 2018 at 01:32:50PM -0800, Cong Wang wrote:
> >
> > This is true only when there is a skb_checksum_init*() or
> > skb_checksum_validate*() prior to it, it seems not true for
> > nf_ip_checksum() where skb->csum is correctly set t
On Fri, Nov 16, 2018 at 01:32:50PM -0800, Cong Wang wrote:
>
> This is true only when there is a skb_checksum_init*() or
> skb_checksum_validate*() prior to it, it seems not true for
> nf_ip_checksum() where skb->csum is correctly set to pesudo header
> checksum but there is no validation of the or
From: Herbert Xu
Date: Fri, 16 Nov 2018 09:52:42 +0800
> netdev_rx_csum_fault is meant to warn about the situation where
> a packet with a valid checksum (i.e., sum == 0) was given to us
> by the hardware with a partial checksum that was invalid.
Thanks for reminding us how this code is supposed
On 11/16/2018 12:15 PM, Cong Wang wrote:
> On Thu, Nov 15, 2018 at 8:52 PM Eric Dumazet wrote:
>>
>> It is very possible NIC provides an incorrect CHECKSUM_COMPLETE, in the
>> case non zero trailer bytes were added by a buggy switch (or host)
>>
>> Saeed can comment/confirm, but the theory is t
On Fri, Nov 16, 2018 at 12:06 PM Cong Wang wrote:
>
> Hmm, now I see how it works. Actually it uses the differences between
> these two check's as the difference between hardware checksum with
> skb_checksum().
>
Well...
This is true only when there is a skb_checksum_init*() or
skb_checksum_vali
On Thu, Nov 15, 2018 at 8:52 PM Eric Dumazet wrote:
>
> It is very possible NIC provides an incorrect CHECKSUM_COMPLETE, in the
> case non zero trailer bytes were added by a buggy switch (or host)
>
> Saeed can comment/confirm, but the theory is that the NIC does header
> analysis and
> computes
On Thu, Nov 15, 2018 at 8:59 PM Herbert Xu wrote:
>
> On Thu, Nov 15, 2018 at 08:52:23PM -0800, Eric Dumazet wrote:
> >
> > It is very possible NIC provides an incorrect CHECKSUM_COMPLETE, in the
> > case non zero trailer bytes were added by a buggy switch (or host)
>
> We should probably change n
On Thu, Nov 15, 2018 at 8:50 PM Herbert Xu wrote:
>
> On Thu, Nov 15, 2018 at 06:23:38PM -0800, Cong Wang wrote:
> >
> > > Normally if the hardware's partial checksum is valid then we just
> > > trust it and send the packet along. However, if the partial
> > > checksum is invalid we don't trust i
On Thu, Nov 15, 2018 at 08:52:23PM -0800, Eric Dumazet wrote:
>
> It is very possible NIC provides an incorrect CHECKSUM_COMPLETE, in the
> case non zero trailer bytes were added by a buggy switch (or host)
We should probably change netdev_rx_csum_fault to print out at
least one complete packet pl
On 11/15/2018 06:23 PM, Cong Wang wrote:
> On Thu, Nov 15, 2018 at 5:52 PM Herbert Xu
> wrote:
>>
>> On Thu, Nov 15, 2018 at 03:16:02PM -0800, Cong Wang wrote:
>>> The following evidences indicate this check is likely wrong:
>>>
>>> 1. In the assignment "skb->csum_valid = !sum", sum==0 indicat
On Thu, Nov 15, 2018 at 06:23:38PM -0800, Cong Wang wrote:
>
> > Normally if the hardware's partial checksum is valid then we just
> > trust it and send the packet along. However, if the partial
> > checksum is invalid we don't trust it and we will compute the
> > whole checksum manually which is
On Thu, Nov 15, 2018 at 5:52 PM Herbert Xu wrote:
>
> On Thu, Nov 15, 2018 at 03:16:02PM -0800, Cong Wang wrote:
> > The following evidences indicate this check is likely wrong:
> >
> > 1. In the assignment "skb->csum_valid = !sum", sum==0 indicates a valid
> > checksum.
> >
> > 2. __skb_checksum
On Thu, Nov 15, 2018 at 03:16:02PM -0800, Cong Wang wrote:
> The following evidences indicate this check is likely wrong:
>
> 1. In the assignment "skb->csum_valid = !sum", sum==0 indicates a valid
> checksum.
>
> 2. __skb_checksum_complete() always returns sum, and TCP packets are dropped
>
The following evidences indicate this check is likely wrong:
1. In the assignment "skb->csum_valid = !sum", sum==0 indicates a valid
checksum.
2. __skb_checksum_complete() always returns sum, and TCP packets are dropped
only when it returns non-zero. So non-zero indicates a failure.
3. In __
21 matches
Mail list logo
