From: "David S. Miller" <davem@redhat.com>
To: James Morris <jmorris@redhat.com>
Cc: mika.penttila@kolumbus.fi, laforge@netfilter.org,
netdev@oss.sgi.com, sds@epoch.ncsc.mil
Subject: Re: [PATCH] Fix checksum bug for multicast/broadcast packets on postrouting hook
Date: Wed, 18 Feb 2004 17:24:41 -0800 [thread overview]
Message-ID: <20040218172441.2eb117a7.davem@redhat.com> (raw)
In-Reply-To: <Xine.LNX.4.44.0402160843570.15855-100000@thoron.boston.redhat.com>
On Mon, 16 Feb 2004 08:45:47 -0500 (EST)
James Morris <jmorris@redhat.com> wrote:
> On Mon, 16 Feb 2004, Mika Penttilä wrote:
>
> > James Morris wrote:
> >
> > >No, it's not needed by all callers, and is just a does-one-thing helper
> > >function.
> > >
> > >
> > It is needed for cloned skbs, so check for this should go in
> > skb_checksum_help().
>
> No, there is no need to bloat a simple helper function out with this
> (and then need to handle OOM internally etc.), and it is not appropriate
> for all callers.
I think Mika is in a way correct James.
Nobody may mangle packet data contents without unsharing SKB on output path.
But things are not so simple. Just mucking with the checksum works because
things which usually clone such packets (TCP retransmit queue) regenerate all
headers and thus checksum fields upon each further use of such clones.
I am tempted just to punish nf_hook_slow()'s invocation of skb_checksum_help()
but that is not the right answer.
Let us look at some of the other users of skb_checksum_help(). The one in dev_queue_xmit()
and the IPSEC encapsulator xfrm drivers are doing so just to plug up a short lived race where
a route lookup points to a non-IPSEC checksumming hardware path, but we end up in the IPSEC
path or to a device which does not support hw checksumming.
One could argue that what we could do in this case is just drop the packet and let the route
relookup on retransmit get things right. This reminds me that we should audit and if necessary
fix handling of the ethtool operations that turn on/off checksumming support, they would need
to flush all of the cached checksumming capability state if they not do so already.
I'm as confused as when we began this thread :-)
I believe it is possible to replace all skb_checksum_help() calls with a packet drop, except
for the nf_hook_slow() case. It may be possible to instead push the nf_hook_slow() instance
simply deeper into the netfilter code so that the iterate/parse/match phase need not invoke
such a heavy operation. Only if netfilter will actually do something with the packet would
we skb_checksum_help() or whatever. And I even believe that most cases where the packet is
mangled do not need to keep from still letting the card checksum the packet.
next prev parent reply other threads:[~2004-02-19 1:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-14 18:37 [PATCH] Fix checksum bug for multicast/broadcast packets on postrouting hook James Morris
2004-02-14 18:37 ` Harald Welte
2004-02-14 19:07 ` Mika Penttilä
2004-02-14 23:00 ` David S. Miller
2004-02-15 6:09 ` James Morris
2004-02-15 9:34 ` Mika Penttilä
2004-02-15 13:03 ` James Morris
2004-02-15 13:40 ` Mika Penttilä
2004-02-15 14:03 ` James Morris
2004-02-15 16:00 ` Mika Penttilä
2004-02-16 1:50 ` James Morris
2004-02-16 6:43 ` Mika Penttilä
2004-02-16 13:45 ` James Morris
2004-02-19 1:24 ` David S. Miller [this message]
2004-02-23 22:19 ` James Morris
2004-02-29 5:50 ` David S. Miller
2004-02-17 15:54 ` Harald Welte
2004-02-17 20:35 ` James Morris
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=20040218172441.2eb117a7.davem@redhat.com \
--to=davem@redhat.com \
--cc=jmorris@redhat.com \
--cc=laforge@netfilter.org \
--cc=mika.penttila@kolumbus.fi \
--cc=netdev@oss.sgi.com \
--cc=sds@epoch.ncsc.mil \
/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).