From: Christian Lamparter <chunkeey@googlemail.com>
To: Jay Smith <jay@kentik.com>
Cc: Christian Lamparter <chunkeey@googlemail.com>,
Alan Curry <rlwinm@sdf.org>,
Eric Dumazet <eric.dumazet@gmail.com>,
netdev@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: UDP wierdness around skb_copy_and_csum_datagram_msg()
Date: Fri, 30 Sep 2016 20:40:44 +0200 [thread overview]
Message-ID: <2193954.GuvoBo3fQP@debian64> (raw)
In-Reply-To: <87a8epp9ya.fsf@kentik.com>
On Friday, September 30, 2016 10:35:25 AM CEST Jay Smith wrote:
> Christian Lamparter writes:
> > On Wednesday, September 28, 2016 7:20:39 PM CEST Jay Smith wrote:
> >> Actually, on a little more searching of this list's archives, I think
> >> that this discussion: https://patchwork.kernel.org/patch/9260733/ is
> >> about exactly the same issue I've found, except from the TCP side. I'm
> >> cc'ing a few of the participants from that discussion.
> >>
> >> So is the patch proposed there (copying and restoring the entire
> >> iov_iter in skb_copy_and_csum_datagram_msg()) being considered as a
> >> fix?
> >
> > From Alan's post:
> >
> > "My ugly patch fixes this in the most obvious way: make a local copy of
> > msg->msg_iter before the call to skb_copy_and_csum_datagram(), and copy
> > it back if the checksum is bad, just before goto csum_error;"
> >
> > IMHO this meant that the patch is a proof of concept for his problem.
>
> It's also the simplest thing that fixes all of the relevant cases (udp4,
> udp6, tcp4).
Al Viro noted that tcp needed more work here (tp->ucopy.len and friends).
Trouble is, that this discussion (between Alan, David, me and Eric) was
offlist at that point... And it doesn't look like anyone involved
wants to repeat what they have already said/written.
(Al Viro, are you there?)
> [...]
> > As for fixing the issue: I'm happy to test and review patches.
> > The trouble is that nobody seem to be able to produce them...
>
> Sorry -- is the trouble you're talking about here that no-one's produced
> a patch, or that we don't have a reproduction of the problem? I don't
> think either is true.
Reproduction wasn't the issue. Back in August, I posted method
which used the network emulator (CONFIG_NET_SCH_NETEM) to reproduce
it easily and almost anywhere [0].
(i.e.: run this on the server/router)
# tc qdisc add dev eth0 root netem corrupt 0.1%
Alan also wrote a userspace tool that had a select/noselect switch
which would lead to different outcomes... etc. However, in the end
Alan could fix his issue by switching to CCMP(AES WLAN cipher),
which he reported fixed his corruption issue.
So sadly yes, what I meant was that the patches are missing in action.
Regards,
Christian
[0] <https://lkml.org/lkml/2016/8/3/181>
next prev parent reply other threads:[~2016-09-30 18:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-29 0:18 UDP wierdness around skb_copy_and_csum_datagram_msg() Jay Smith
2016-09-29 1:24 ` Eric Dumazet
2016-09-29 2:20 ` Jay Smith
2016-09-29 23:28 ` Christian Lamparter
2016-09-30 0:06 ` Eric Dumazet
2016-09-30 17:35 ` Jay Smith
2016-09-30 18:40 ` Christian Lamparter [this message]
2016-10-17 17:10 ` Jay Smith
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=2193954.GuvoBo3fQP@debian64 \
--to=chunkeey@googlemail.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=jay@kentik.com \
--cc=netdev@vger.kernel.org \
--cc=rlwinm@sdf.org \
--cc=viro@zeniv.linux.org.uk \
/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).