From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH net] net: fix pskb_trim_rcsum_slow() with odd trim offset Date: Fri, 19 Oct 2018 17:13:59 -0700 Message-ID: References: <20181020000713.228659-1-dmichail@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org To: Dimitris Michailidis , edumazet@google.com, davem@davemloft.net Return-path: Received: from mail-pf1-f196.google.com ([209.85.210.196]:47097 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726513AbeJTIWZ (ORCPT ); Sat, 20 Oct 2018 04:22:25 -0400 Received: by mail-pf1-f196.google.com with SMTP id r64-v6so17150764pfb.13 for ; Fri, 19 Oct 2018 17:14:02 -0700 (PDT) In-Reply-To: <20181020000713.228659-1-dmichail@google.com> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 10/19/2018 05:07 PM, Dimitris Michailidis wrote: > We've been getting checksum errors involving small UDP packets, usually > 59B packets with 1 extra non-zero padding byte. netdev_rx_csum_fault() > has been complaining that HW is providing bad checksums. Turns out the > problem is in pskb_trim_rcsum_slow(), introduced in commit 88078d98d1bb > ("net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends"). > > The source of the problem is that when the bytes we are trimming start > at an odd address, as in the case of the 1 padding byte above, > skb_checksum() returns a byte-swapped value. We cannot just combine this > with skb->csum using csum_sub(). We need to use csum_block_sub() here > that takes into account the parity of the start address and handles the > swapping. > > Matches existing code in __skb_postpull_rcsum() and esp_remove_trailer(). > > Fixes: 88078d98d1bb ("net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends") > Signed-off-by: Dimitris Michailidis Thanks a lot Dimitris for finding this. Reviewed-by: Eric Dumazet