summaryrefslogtreecommitdiffstats
path: root/kernel/bounds.c
diff options
context:
space:
mode:
authorLepton Wu <ytht.net@gmail.com>2018-12-11 11:12:55 -0800
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2019-12-05 09:20:19 +0100
commit7e976ccc4f0666131f1a59d01b958b3e51718084 (patch)
treebe433e42a338f0686ecc7348dcb7c1d9106bf41c /kernel/bounds.c
parente58133e43cb0005524cc8f789e340e797153a6fb (diff)
downloadlinux-stable-7e976ccc4f0666131f1a59d01b958b3e51718084.tar.gz
linux-stable-7e976ccc4f0666131f1a59d01b958b3e51718084.tar.bz2
linux-stable-7e976ccc4f0666131f1a59d01b958b3e51718084.zip
VSOCK: bind to random port for VMADDR_PORT_ANY
[ Upstream commit 8236b08cf50f85bbfaf48910a0b3ee68318b7c4b ] 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 <ytht.net@gmail.com> Reviewed-by: Jorgen Hansen <jhansen@vmware.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'kernel/bounds.c')
0 files changed, 0 insertions, 0 deletions