The old code always starts from fixed port for VMADDR_PORT_ANY. Sometimes
when VMM crashed, there is still orphaned vsock which is waiting for
close timer, then it could cause connection time out for new started VM
if they are trying to connect to same port with same guest cid since the
new packets could hit that orphaned vsock. We could also fix this by doing
more in vhost_vsock_reset_orphans, but any way, it should be better to start
from a random local port instead of a fixed one.
Signed-off-by: Lepton Wu <redacted>
---
net/vmw_vsock/af_vsock.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
From: Stefan Hajnoczi <stefanha@redhat.com> Date: 2018-12-11 16:26:52
On Mon, Dec 10, 2018 at 11:02:35PM -0800, Lepton Wu wrote:
The old code always starts from fixed port for VMADDR_PORT_ANY. Sometimes
when VMM crashed, there is still orphaned vsock which is waiting for
close timer, then it could cause connection time out for new started VM
if they are trying to connect to same port with same guest cid since the
new packets could hit that orphaned vsock. We could also fix this by doing
more in vhost_vsock_reset_orphans, but any way, it should be better to start
from a random local port instead of a fixed one.
Signed-off-by: Lepton Wu <redacted>
---
net/vmw_vsock/af_vsock.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
Jorgen, Dexuan: Any objection to this? It also affects the other
AF_VSOCK transports.
From: Jorgen S. Hansen <hidden> Date: 2018-12-11 18:53:09
On Mon, Dec 10, 2018 at 11:02:35PM -0800, Lepton Wu wrote:
quoted
The old code always starts from fixed port for VMADDR_PORT_ANY. Sometimes
when VMM crashed, there is still orphaned vsock which is waiting for
close timer, then it could cause connection time out for new started VM
if they are trying to connect to same port with same guest cid since the
new packets could hit that orphaned vsock. We could also fix this by doing
more in vhost_vsock_reset_orphans, but any way, it should be better to start
from a random local port instead of a fixed one.
Signed-off-by: Lepton Wu <redacted>
---
net/vmw_vsock/af_vsock.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
Jorgen, Dexuan: Any objection to this? It also affects the other
AF_VSOCK transports.
How about making this:
port = LAST_RESERVED_PORT + 1 + prandom_u32_max(U32_MAX - LAST_RESERVED_PORT);
so the initial assignment is a valid port in the unreserved range. It will be corrected in the first iteration,
but this would make the intention clearer.
quoted
vsock_addr_init(&new_addr, addr->svm_cid, addr->svm_port);
if (addr->svm_port == VMADDR_PORT_ANY) {
--
2.20.0.rc2.403.gdbc3b29805-goog
The old code always starts from fixed port for VMADDR_PORT_ANY. Sometimes
when VMM crashed, there is still orphaned vsock which is waiting for
close timer, then it could cause connection time out for new started VM
if they are trying to connect to same port with same guest cid since the
new packets could hit that orphaned vsock. We could also fix this by doing
more in vhost_vsock_reset_orphans, but any way, it should be better to start
from a random local port instead of a fixed one.
Signed-off-by: Lepton Wu <redacted>
---
net/vmw_vsock/af_vsock.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
From: Dexuan Cui <decui@microsoft.com> Date: 2018-12-12 08:23:29
From: Stefan Hajnoczi <stefanha@redhat.com>
Sent: Tuesday, December 11, 2018 8:27 AM
To: Jorgen Hansen <redacted>; Dexuan Cui
[off-list ref]
Cc: netdev@vger.kernel.org; Lepton Wu <redacted>
Subject: Re: [PATCH] VSOCK: bind to random port for VMADDR_PORT_ANY
On Mon, Dec 10, 2018 at 11:02:35PM -0800, Lepton Wu wrote:
quoted
The old code always starts from fixed port for VMADDR_PORT_ANY.
Sometimes
quoted
when VMM crashed, there is still orphaned vsock which is waiting for
close timer, then it could cause connection time out for new started VM
if they are trying to connect to same port with same guest cid since the
new packets could hit that orphaned vsock. We could also fix this by doing
more in vhost_vsock_reset_orphans, but any way, it should be better to start
from a random local port instead of a fixed one.
Signed-off-by: Lepton Wu <redacted>
---
net/vmw_vsock/af_vsock.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
Jorgen, Dexuan: Any objection to this? It also affects the other
AF_VSOCK transports.
Thanks for letting me notice the patch. :-)
Now I saw Lepton's v2 patch, which looks good to me.
Thanks,
-- Dexuan
From: Jorgen S. Hansen <hidden> Date: 2018-12-12 13:22:09
quoted hunk
The old code always starts from fixed port for VMADDR_PORT_ANY.
Sometimes when VMM crashed, there is still orphaned vsock which is waiting
for close timer, then it could cause connection time out for new started VM if
they are trying to connect to same port with same guest cid since the new
packets could hit that orphaned vsock. We could also fix this by doing more in
vhost_vsock_reset_orphans, but any way, it should be better to start from a
random local port instead of a fixed one.
Signed-off-by: Lepton Wu <redacted>
---
net/vmw_vsock/af_vsock.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c index
The old code always starts from fixed port for VMADDR_PORT_ANY. Sometimes
when VMM crashed, there is still orphaned vsock which is waiting for
close timer, then it could cause connection time out for new started VM
if they are trying to connect to same port with same guest cid since the
new packets could hit that orphaned vsock. We could also fix this by doing
more in vhost_vsock_reset_orphans, but any way, it should be better to start
from a random local port instead of a fixed one.
Signed-off-by: Lepton Wu <redacted>