netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Tom Herbert <tom@herbertland.com>
Cc: Jesse Brandeburg <jesse.brandeburg@gmail.com>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>
Subject: Re: [RFC PATCH] Fix false positives in can_checksum_protocol()
Date: Mon, 05 Oct 2015 12:16:57 +0100	[thread overview]
Message-ID: <1444043817.4674.162.camel@infradead.org> (raw)
In-Reply-To: <CALx6S35Jg1fOCkXM3zkzPW=GbKV0Ake5NKc8iq2CJ255nKJgag@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]

On Tue, 2015-09-29 at 15:52 -0700, Tom Herbert wrote:
> Please look at ixgbe_tx_csum in ixgbe driver. This one example of how
> a driver can determine whether the checksum being offloaded is TCP or
> UDP. The bug in this driver is...

I think it serves better as an example of why we don't *want* drivers
doing that kind of thing for themselves... :)

I propose we steal some high bits from csum_offset, as you suggested,
and use them to indicate a 'checksum type', which will include TCP and
UDP.

Then the filter in netif_skb_features() can trivially do the right
thing for NETIF_F_IP{V6,}_CSUM devices, so avoid feeding them packets
they can't handle.

You mentioned that you actually want to deprecate those feature flags —
which works for me, but it's kind of orthogonal. If we do that we'd
still want to provide generic functions that such drivers can use as
their .ndo_features_check() method. And we'd *still* want to do the
check based on a simple flag, rather than grubbing around in the packet
data. (And the drivers if they *are* asked to do the checksum will
sometimes care whether it's TCP vs. UDP too).

I don't think we want drivers calling skb_checksum_help() for
themselves; we want the pre-filter. Mainly because we *definitely*
don't want drivers calling gso_skb_segment() for themselves in the same
situation — see the comment I posted on Friday about the r8169 instance
of that. ('Re: [PATCH net-next 3/3] r8169: support IPv6').

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

  reply	other threads:[~2015-10-05 11:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-25 12:55 [RFC PATCH] Fix false positives in can_checksum_protocol() David Woodhouse
2015-09-28 17:03 ` Tom Herbert
2015-09-28 18:27   ` David Woodhouse
2015-09-28 19:13     ` Tom Herbert
2015-09-28 19:26       ` David Woodhouse
2015-09-28 19:37         ` Tom Herbert
2015-09-29  1:38           ` Jesse Brandeburg
2015-09-29  3:04             ` Tom Herbert
2015-09-29  7:12               ` David Woodhouse
2015-09-29 22:52                 ` Tom Herbert
2015-10-05 11:16                   ` David Woodhouse [this message]
2015-10-05 16:23                     ` Tom Herbert
2015-10-05 18:28                       ` Rustad, Mark D
2015-10-05 20:22                       ` David Woodhouse
2015-09-29  7:08           ` David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1444043817.4674.162.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=jesse.brandeburg@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=tom@herbertland.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).