From: "Prout, Andrew - LLSC - MITLL" <aprout@ll.mit.edu>
To: Eric Dumazet <eric.dumazet@gmail.com>,
Christoph Paasch <christoph.paasch@gmail.com>
Cc: "David S . Miller" <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jonathan Looney <jtl@netflix.com>,
Neal Cardwell <ncardwell@google.com>,
Tyler Hicks <tyhicks@canonical.com>,
Yuchung Cheng <ycheng@google.com>,
Bruce Curtis <brucec@netflix.com>,
Jonathan Lemon <jonathan.lemon@gmail.com>,
"Dustin Marquess" <dmarquess@apple.com>
Subject: RE: [PATCH net 2/4] tcp: tcp_fragment() should apply sane memory limits
Date: Tue, 16 Jul 2019 15:13:15 +0000 [thread overview]
Message-ID: <23c64fbdcdb14517a01afaecc370a914@ll.mit.edu> (raw)
In-Reply-To: <adec774ed16540c6b627c2f607f3e216@ll.mit.edu>
On 7/11/2019 11:15 PM, Prout, Andrew - LLSC - MITLL wrote:
> I in no way intended to imply that I had confirmed the small SO_SNDBUF was a prerequisite to our problem. With my synthetic test, I was looking for a concise reproducer and trying things to > stress the system.
I've looked into this some more: I am now able to reproduce it consistently (on 4.14.132) with my synthetic test seemingly regardless of the SO_SNDBUF size (tested 128KiB, 512KiB, 1MiB and 10MiB). The key change to make it reproducible was to use sendfile() instead of send() - this is what samba was doing in our real failure case. Looking at the code, it appears that sendfile() calls into the zerocopy functions which only check SNDBUF for memory they allocate (the skb structure) - they'll happily "overfill" the send buffer with zerocopy'd pages.
In my tests I can see the send buffer used reported by netstat getting to much larger values than the SO_SNDBUF value I set (with a 10MiB SO_SNDBUF, it got up to ~52MiB on a stalled connection). This of course easily causes the CVE-2019-11478 fix to false alarm and the TCP connection to stall.
next prev parent reply other threads:[~2019-07-16 15:24 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-17 17:03 [PATCH net 0/4] tcp: make sack processing more robust Eric Dumazet
2019-06-17 17:03 ` [PATCH net 1/4] tcp: limit payload size of sacked skbs Eric Dumazet
2019-06-17 17:14 ` Jonathan Lemon
2019-06-17 17:03 ` [PATCH net 2/4] tcp: tcp_fragment() should apply sane memory limits Eric Dumazet
2019-06-17 17:14 ` Jonathan Lemon
2019-06-18 0:18 ` Christoph Paasch
2019-06-18 2:28 ` Eric Dumazet
2019-06-18 3:19 ` Christoph Paasch
2019-06-18 3:44 ` Eric Dumazet
2019-06-18 3:53 ` Christoph Paasch
2019-06-18 4:08 ` Eric Dumazet
2019-07-10 18:23 ` Prout, Andrew - LLSC - MITLL
2019-07-10 18:28 ` Eric Dumazet
2019-07-10 18:53 ` Prout, Andrew - LLSC - MITLL
2019-07-10 19:26 ` Eric Dumazet
2019-07-11 7:28 ` Christoph Paasch
2019-07-11 9:19 ` Eric Dumazet
2019-07-11 18:26 ` Michal Kubecek
2019-07-11 18:50 ` Eric Dumazet
2019-07-11 10:18 ` Eric Dumazet
2019-07-11 17:14 ` Prout, Andrew - LLSC - MITLL
2019-07-11 18:28 ` Eric Dumazet
2019-07-11 19:04 ` Jonathan Lemon
2019-07-12 7:05 ` Eric Dumazet
2019-07-16 15:13 ` Prout, Andrew - LLSC - MITLL [this message]
2019-06-17 17:03 ` [PATCH net 3/4] tcp: add tcp_min_snd_mss sysctl Eric Dumazet
2019-06-17 17:15 ` Jonathan Lemon
2019-06-17 17:18 ` Tyler Hicks
2019-06-17 17:03 ` [PATCH net 4/4] tcp: enforce tcp_min_snd_mss in tcp_mtu_probing() Eric Dumazet
2019-06-17 17:16 ` Jonathan Lemon
2019-06-17 17:18 ` Tyler Hicks
2019-06-17 17:41 ` [PATCH net 0/4] tcp: make sack processing more robust David Miller
2019-08-02 19:02 [PATCH net 2/4] tcp: tcp_fragment() should apply sane memory limits Bernd
2019-08-02 19:14 ` Neal Cardwell
2019-08-02 19:58 ` Bernd
2019-08-14 14:41 ` Marcelo Ricardo Leitner
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=23c64fbdcdb14517a01afaecc370a914@ll.mit.edu \
--to=aprout@ll.mit.edu \
--cc=brucec@netflix.com \
--cc=christoph.paasch@gmail.com \
--cc=davem@davemloft.net \
--cc=dmarquess@apple.com \
--cc=eric.dumazet@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jonathan.lemon@gmail.com \
--cc=jtl@netflix.com \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=tyhicks@canonical.com \
--cc=ycheng@google.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).