---1463786494-729937714-970752709=:617
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
had some long network stalls during initscripts in 2.4.0-test9.
newaliases appeared to block until timeout in do_poll() on udp socket.
I've written a demo program to show what's going on without depending
on initscript and config (DNS/RPC/NIS) issues - attached polltest.c
It sends something to an *unbound* udp port on localhost and polls for
reply. In 2.2.16 it returned immediately with ECONNREFUSED while for
2.4.0-t9 it blocks until timout, despite the ICMP port unreachable packet
returned in both cases - tcpdump -i lo gives:
14:05:13.591422 localhost.localdomain.32768 > localhost.localdomain.12345:
udp 8 (DF)
14:05:13.591422 localhost.localdomain.32768 > localhost.localdomain.12345:
udp 8 (DF)
14:05:13.591527 localhost.localdomain > localhost.localdomain: icmp:
localhost.localdomain udp port 12345 unreachable (DF) [tos 0xc0]
14:05:13.591527 localhost.localdomain > localhost.localdomain: icmp:
localhost.localdomain udp port 12345 unreachable (DF) [tos 0xc0]
(i believe everything appears twice because tcpdump sees both ends of lo)
So my impression is, the returned ICMP packet is disregarded somehow.
I also include a diff of the straces for polltest on 2.2.16 vs.
2.4.0-t9 (trivial things like getpid, gettimeofday, fstat64 removed):
--- polltrace-2.2.16 Thu Oct 5 13:57:13 2000
+++ polltrace-2.4.0-t9 Thu Oct 5 14:05:23 2000
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
bind(3, {sin_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("0.0.0.0")}}, 16) = 0
sendto(3, "foo bar\0", 8, 0, {sin_family=AF_INET, sin_port=htons(12345),
sin_addr=inet_addr("127.0.0.1")}}, 16) = 8
-poll([{fd=3, events=POLLIN, revents=POLLERR}], 1, 10000) = 1
-recvfrom(3, 0xbffffcbc, 100, 0, 0xbffffd24, 0xbffffcb8) = -1 ECONNREFUSED
(Connection refused)
+poll([{fd=3, events=POLLIN}], 1, 10000) = 0
-write(1, "recvfrom: errno=111 - Connection"..., 41) = 41
+write(1, "poll - timeout\n", 15) = 15
To reproduce the problem just start polltest on 2.2.16 (or similar ?) and
recent 2.4 to compare the results. It accepts an optional command line
argument which is the remote port to poll on. This should be an unbound
port and defaults to 12345 if not given.
Is this an intentional change? Is it required by SuS e.g.?
Am I completely wrong when believing this might brake a number of
network programs (traceroute e.g.)?
Haven't tried neither non-loopback connection nor other
tcp/udp/poll/select combinations. But sane semantics should be consistent
IMHO. The testbox was UP in case that matters (lost events at scheduling
points???)
What am I missing?
Regards
Martin
---1463786494-729937714-970752709=:617
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="polltest.c"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.10010051531490.617@notebook.diehl.home>
Content-Description: polltest.c
Content-Disposition: attachment; filename="polltest.c"
DQojaW5jbHVkZSA8c3RkaW8uaD4NCiNpbmNsdWRlIDx1bmlzdGQuaD4NCiNp
bmNsdWRlIDxzdHJpbmcuaD4NCiNpbmNsdWRlIDxlcnJuby5oPg0KI2luY2x1
ZGUgPG5ldGluZXQvaW4uaD4NCiNpbmNsdWRlIDxzeXMvc29ja2V0Lmg+DQoj
aW5jbHVkZSA8c3lzL3BvbGwuaD4NCg0KaW5saW5lIGludCBDaGVja0Vyck91
dCggaW50IHJldGNvZGUsIGNvbnN0IGNoYXIgKm1zZyApDQp7DQogIGlmIChy
ZXRjb2RlICE9IC0xKQ0KICAgIHJldHVybiAwOw0KICBwcmludGYoIiVzOiBl
cnJubz0lZCAtICVzXG4iLCBtc2csIGVycm5vLCBzdHJlcnJvcihlcnJubykp
Ow0KICBleGl0KDEpOw0KfQ0KDQppbnQgbWFpbihpbnQgYXJnYywgY2hhciAq
YXJndltdKQ0Kew0KICBjb25zdCBjaGFyICAgICAgICAgIHNlbmRfbXNnW10g
PSAiZm9vIGJhciI7DQogIGludCAgICAgICAgICAgICAgICAgcmV0ID0gMDsN
CiAgaW50ICAgICAgICAgICAgICAgICBmZCA9IC0xOw0KICBzdHJ1Y3QgcG9s
bGZkICAgICAgIHBmZDsNCiAgc3RydWN0IHNvY2thZGRyX2luICBmcm9tLCB0
bzsNCiAgaW50ICAgICAgICAgICAgICAgICBwb3J0ID0gMDsNCg0KICBpZiAo
YXJnYyA+IDEgICYmICBzc2NhbmYoYXJndlsxXSwgIiAlZCIsICZwb3J0KT09
MSkNCiAgICA7DQogIGVsc2UNCiAgICBwb3J0ID0gMTIzNDU7DQoNCiAgZmQg
PSBzb2NrZXQoUEZfSU5FVCxTT0NLX0RHUkFNLElQUFJPVE9fVURQKTsNCiAg
Q2hlY2tFcnJPdXQoZmQsInNvY2tldCIpOw0KDQogIG1lbXNldCgmZnJvbSww
LHNpemVvZihmcm9tKSk7DQogIGZyb20uc2luX2ZhbWlseSA9IEFGX0lORVQ7
DQogIGZyb20uc2luX2FkZHIuc19hZGRyID0gSU5BRERSX0FOWTsNCiAgZnJv
bS5zaW5fcG9ydCA9IDA7DQogIHJldCA9IGJpbmQoZmQsJmZyb20sc2l6ZW9m
KGZyb20pKTsNCiAgQ2hlY2tFcnJPdXQocmV0LCJiaW5kIik7DQoNCiAgbWVt
c2V0KCZ0bywwLHNpemVvZih0bykpOw0KICB0by5zaW5fZmFtaWx5ID0gQUZf
SU5FVDsNCiAgdG8uc2luX2FkZHIuc19hZGRyID0gaHRvbmwoSU5BRERSX0xP
T1BCQUNLKTsNCiAgdG8uc2luX3BvcnQgPSBodG9ucyhwb3J0KTsNCiAgcmV0
ID0gc2VuZHRvKGZkLHNlbmRfbXNnLHNpemVvZihzZW5kX21zZyksMCwmdG8s
c2l6ZW9mKHRvKSk7DQogIENoZWNrRXJyT3V0KHJldCwic2VuZHRvIik7DQog
IA0KICBtZW1zZXQoJnBmZCwwLHNpemVvZihwZmQpKTsNCiAgcGZkLmZkID0g
ZmQ7DQogIHBmZC5ldmVudHMgPSBQT0xMSU47ICANCiAgcmV0ID0gcG9sbCgm
cGZkLDEsMTAwMDApOw0KICBDaGVja0Vyck91dChyZXQsInBvbGwiKTsNCg0K
ICBpZiAocmV0ICE9IDApIHsNCiAgICBjaGFyICAgcmVjdl9idWZbMTAwXTsN
CiAgICBpbnQgICAgYWRkcmxlbjsNCiAgICANCiAgICByZXQgPSByZWN2ZnJv
bShmZCxyZWN2X2J1ZixzaXplb2YocmVjdl9idWYpLDAsJnRvLCZhZGRybGVu
KTsNCiAgICBDaGVja0Vyck91dChyZXQsInJlY3Zmcm9tIik7DQogICAgcHJp
bnRmKCJyZWNlaXZlZDogJXUgYnl0ZXNcbiIsIHJldCk7DQogIH0NCiAgZWxz
ZQ0KICAgIHByaW50ZigicG9sbCAtIHRpbWVvdXRcbiIpOw0KIA0KICBjbG9z
ZShmZCk7DQogIHJldHVybiAwOw0KfQ0K
---1463786494-729937714-970752709=:617--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/