Re: virt-manager broken by bind(0) in net-next.
From: Stephen Hemminger <hidden>
Date: 2009-02-01 05:29:09
On Fri, 30 Jan 2009 19:41:59 +0100 Eric Dumazet [off-list ref] wrote:
quoted hunk
Stephen Hemminger a écrit :quoted
On Fri, 30 Jan 2009 23:53:37 +1100 Herbert Xu [off-list ref] wrote:quoted
Evgeniy Polyakov [off-list ref] wrote:quoted
So it is not explicit bind call, but port autoselection in the connect(). Can you check what errno is returned? Did I understand it right, that connect fails, you try different address, but then suddenly all those sockets become 'alive'?Yes, I think a good strace vs. a bad strace would be really helpful in these cases. Thanks,I have the strace but it comes up no different. What is different is that in the broken case (net-next), I see IPV6 being used: State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 23769 0 ::ffff:127.0.0.1:5900 ::ffff:127.0.0.1:55987 ESTAB 0 0 127.0.0.1:55987 127.0.0.1:5900 and in the working case (2.6.29-rc3), IPV4 is being used State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 0 127.0.0.1:58894 127.0.0.1:5901 ESTAB 0 0 127.0.0.1:5901 127.0.0.1:58894Reviewing commit a9d8f9110d7e953c2f2b521087a4179677843c2a I see use of a hashinfo->bsockets field that : - lacks proper lock/synchronization - suffers from cache line ping pongs on SMP Also there might be a problem at line 175 if (sk->sk_reuse && sk->sk_state != TCP_LISTEN && --attempts >= 0) { spin_unlock(&head->lock); goto again; If we entered inet_csk_get_port() with a non null snum, we can "goto again" while it was not expected.diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c index df8e72f..752c6b2 100644 --- a/net/ipv4/inet_connection_sock.c +++ b/net/ipv4/inet_connection_sock.c@@ -172,7 +172,8 @@ tb_found: } else { ret = 1; if (inet_csk(sk)->icsk_af_ops->bind_conflict(sk, tb)) { - if (sk->sk_reuse && sk->sk_state != TCP_LISTEN && --attempts >= 0) { + if (sk->sk_reuse && sk->sk_state != TCP_LISTEN && + smallest_size == -1 && --attempts >= 0) { spin_unlock(&head->lock); goto again; }
That didn't fix it.