From: David Woodhouse <dwmw2@infradead.org>
To: Tom Herbert <tom@herbertland.com>
Cc: Linux Kernel Network Developers <netdev@vger.kernel.org>
Subject: Re: [RFC PATCH] Fix false positives in can_checksum_protocol()
Date: Mon, 28 Sep 2015 20:26:21 +0100 [thread overview]
Message-ID: <1443468381.4674.115.camel@infradead.org> (raw)
In-Reply-To: <CALx6S35VXGfCeYtXm9z2APgt=kAwR2qJ5v7psN+Pg17LcDKasw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2086 bytes --]
On Mon, 2015-09-28 at 12:13 -0700, Tom Herbert wrote:
>
> > Perhaps a better solution would be a bit in the skbuff which indicates
> > that it *is* a TCP or UDP checksum. That would be set by our UDP and
> > TCP sockets, cleared by encapsulation, also set if appropriate by
> > skb_partial_csum_set().
> >
> Yes I agree. What I have been thinking to do is steal two bits from
> csum_offset that would indicate that the checksum is IPv4 or IPv6
> (specifically that the checksum value is seeded with an IPv4 or IPv6
> pseudo header). This information plus the csum_offset would be
> sufficient for drivers to identify the checksum as UDP/TCP-IPv4/IPv6.
> The other case that needs special handling is inner vs. outer
> checksum, but that can be deduced by comparing (inner of outer)
> transport offset to checksum start. With this and a couple of utility
> functions we should be able to start deprecating NETIF_F_IP_CSUM and
> NETIF_F_IPV6_CSUM.
You mean drivers which currently set NETIF_F_IP_CSUM would need to
provide a .ndo_features_check() which tolerates only the packets they
can actually handle? And we'd just ensure that the bits are there for
them to use, in the skbuff? That seems reasonable.
Note that 'seeded with an IPv[46] pseudo header' isn't quite
sufficient. Some hardware like 8139cp is explicitly told to do a UDP or
a TCP checksum with a bit in the descriptor, so any UDP-like or TCP
-like checksum works out fine.
Other hardware works out whether to do a UDP or a TCP checksum for
*itself*, so it *can't* cope with other protocols which just happen to
look the same. For those it really *must* be IPPROTO_TCP or IPPROTO_UDP
and they're going to be looking in the IP header for it.
I do suspect we'll want a bit which says it's *actually* TCP or UDP,
not just 'seeded with a pseudo-header'. That's the important
distinction for NETIF_F_IP_CSUM vs. NETIF_F_HW_CSUM.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]
next prev parent reply other threads:[~2015-09-28 19:26 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 [this message]
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
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=1443468381.4674.115.camel@infradead.org \
--to=dwmw2@infradead.org \
--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).