[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20190322084621.365c36fb@shemminger-XPS-13-9360>
Date: Fri, 22 Mar 2019 08:46:21 -0700
From: Stephen Hemminger <stephen@...workplumber.org>
To: netdev@...r.kernel.org
Subject: Fw: [Bug 202997] New: High UDP traffic results in packet receive
errors and system-wide UDP failure
Not sure if this a new problem, or just another case of
"don't expect fragmented packets to be reliable".
Begin forwarded message:
Date: Thu, 21 Mar 2019 22:42:41 +0000
From: bugzilla-daemon@...zilla.kernel.org
To: stephen@...workplumber.org
Subject: [Bug 202997] New: High UDP traffic results in packet receive errors and system-wide UDP failure
https://bugzilla.kernel.org/show_bug.cgi?id=202997
Bug ID: 202997
Summary: High UDP traffic results in packet receive errors and
system-wide UDP failure
Product: Networking
Version: 2.5
Kernel Version: 4.18.19-041819-generic
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
Assignee: stephen@...workplumber.org
Reporter: sagar@...ana.com
Regression: No
Created attachment 281959
--> https://bugzilla.kernel.org/attachment.cgi?id=281959&action=edit
C file that demonstrates the problem
**OS**: Ubuntu 18.04, Ubuntu 18.10
**Kernel**: 4.18.18, 5.0.3
**Hardware**: Razer Blade 15 2018, Google Cloud Platform
Repeatedly sending large (65k) packets to a UDP socket seemingly depletes the
kernel buffers. It results in numerous "packet receive" errors in netstat and
proc/net/udp(however buffer errors are not incremented). While the receiver
sockets are left open, no other UDP traffic is processed(for example - can't
browse the web).
The attached test, client.c, demonstrates this failure. It intentionally uses
waits/whiles to make the failure more evident. The only way to recover UDP
functionality is to kill the test.
Alternatively, closing the receiver socket and rebinding it on ever iteration
mitigates this system-wide failure and the test can remain running. Lines 59-61
in client.c show this.
Neither the sender, nor the receiver socket report any errors (even when the
test is modified to call recv).
I also ran this on the Windows subsystem for Linux without any trouble.
--
You are receiving this mail because:
You are the assignee for the bug.
Powered by blists - more mailing lists