From: Stephen Hemminger <stephen@networkplumber.org>
To: Eric Dumazet <edumazet@google.com>
Cc: netdev@vger.kernel.org
Subject: Fw: [Bug 195713] New: TCP recv queue grows huge
Date: Thu, 11 May 2017 09:47:58 -0700 [thread overview]
Message-ID: <20170511094758.2112b00f@xeon-e3> (raw)
Begin forwarded message:
Date: Thu, 11 May 2017 13:25:23 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 195713] New: TCP recv queue grows huge
https://bugzilla.kernel.org/show_bug.cgi?id=195713
Bug ID: 195713
Summary: TCP recv queue grows huge
Product: Networking
Version: 2.5
Kernel Version: 3.13.0 4.4.0 4.9.0
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
Assignee: stephen@networkplumber.org
Reporter: mkm@nabto.com
Regression: No
I was testing how TCP handled advertising reductions of the window sizes
especially Window Full events. To create this setup I made a slow TCP receiver
and a fast TCP sender. To add some reality to the scenario I simulated 10ms
delay on the loopback device using the netem tc module.
Steps to reproduce:
Bevare these steps will use all the memory on your system
1. create latency on loopback
>sudo tc qdisc change dev lo root netem delay 0ms
2. slow tcp receiver:
>nc -l 4242 | pv -L 1k
3. fast tcp sender:
>nc 127.0.0.1 4242 < /dev/zero
What to expect:
It is expected that the TCP recv queue is not groving unbounded e.g. the
following output from netstat:
>netstat -an | grep 4242
>tcp 5563486 0 127.0.0.1:4242 127.0.0.1:59113
>ESTABLISHED
>tcp 0 3415559 127.0.0.1:59113 127.0.0.1:4242
>ESTABLISHED
What is seen:
The TCP receive queue grows until there is no more memory available on the
system.
>netstat -an | grep 4242
>tcp 223786525 0 127.0.0.1:4242 127.0.0.1:59114
>ESTABLISHED
>tcp 0 4191037 127.0.0.1:59114 127.0.0.1:4242
>ESTABLISHED
Note: After the TCP recv queue reaches ~ 2^31 bytes netstat reports a 0 which
is not correct, it has probably not been created with this bug in mind.
Systems on which the bug reproducible:
* debian testing, kernel 4.9.0
* ubuntu 14.04, kernel 3.13.0
* ubuntu 16.04, kernel 4.4.0
I have not testet on other systems than the above mentioned.
--
You are receiving this mail because:
You are the assignee for the bug.
next reply other threads:[~2017-05-11 16:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-11 16:47 Stephen Hemminger [this message]
2017-05-11 17:06 ` Fw: [Bug 195713] New: TCP recv queue grows huge Eric Dumazet
2017-05-11 19:29 ` Michael Madsen
2017-05-11 19:42 ` Eric Dumazet
2017-05-11 22:24 ` [PATCH net] netem: fix skb_orphan_partial() Eric Dumazet
2017-05-12 1:33 ` David Miller
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=20170511094758.2112b00f@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=edumazet@google.com \
--cc=netdev@vger.kernel.org \
/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