Bug 85091
Summary: | neighbour table overflow is not reported and impacts localhost TCP connectivity | ||
---|---|---|---|
Product: | Networking | Reporter: | Andreas Schultz (aschultz) |
Component: | IPV4 | Assignee: | Stephen Hemminger (stephen) |
Status: | NEW --- | ||
Severity: | normal | CC: | szg00000, xiyou.wangcong |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 3.8 - 3.17-rc6 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
Andreas Schultz
2014-09-24 10:44:11 UTC
What do you mean by "netperf stalls"? When hit gc_thresh3, netperf should get EINVAL and then it should stop unless it ignores syscall return value. I have used netperf only used to make the problem easily producible. Every *established*, local (though lo interface) TCP connection seems to be affected. The TCP connection seems to stall, netstat shows that the send queue of the netperf server process fills up. traces (systemtap) on the processes show that poll is not reporting the socket as having data. Neither the sender nor the receiver side is getting an EINVAL on the syscalls. tcpdump on lo shows a distinct "gap" between a single TCP packet and ACK for it. Sometimes the gap is 20 seconds, sometime much more. Hmm, interesting. loopback traffic should not need a neigh entry at all. How many concurrent TCP connections do you have? Did you see any memory pressure? Thanks. |