Yes, I confirm this is the patch we need for the Enhanced Session mode.
The patch was originally made to fix a different issue, but it can also fix the VM panic we see with Enhanced Session mode, because the cause is the same: there is a race
static int __init hvs_init(void)
{
int ret;
if (vmbus_proto_version < VERSION_WIN10) return -ENODEV;
ret = vmbus_driver_register(&hvs_drv);
if (ret != 0) return ret;
Dexuan: ---------------------------: if the host-initiated connection comes here (e.g. before we call vsock_core_init(), hvs_open_connection() -> vsock_find_bound_socket() -> __vsock_find_bound_socket() can access the uninitialized vsock_bound_sockets(addr) -> vsock_bind_table, which will be initialized in vsock_core_init() -> vsock_init_tables(), and we'll hit a panic.
ret = vsock_core_init(&hvs_transport);
if (ret) { vmbus_driver_unregister(&hvs_drv); return ret;
}
return 0;
}
The latest upstream 4.15.1 kernel has the fix already, but 4.14.17 doesn't have the fix.
Yes, I confirm this is the patch we need for the Enhanced Session mode.
The patch was originally made to fix a different issue, but it can also fix the VM panic we see with Enhanced Session mode, because the cause is the same: there is a race
static int __init hvs_init(void)
{
int ret;
if (vmbus_ proto_version < VERSION_WIN10)
return -ENODEV;
ret = vmbus_driver_ register( &hvs_drv) ;
return ret; ------- ------- ------: if the host-initiated connection comes here (e.g. before we call vsock_core_init(), hvs_open_ connection( ) -> vsock_find_ bound_socket( ) -> __vsock_ find_bound_ socket( ) can access the uninitialized vsock_bound_ sockets( addr) -> vsock_bind_table, which will be initialized in vsock_core_init() -> vsock_init_ tables( ), and we'll hit a panic.
if (ret != 0)
Dexuan: -------
ret = vsock_core_ init(&hvs_ transport) ;
vmbus_ driver_ unregister( &hvs_drv) ;
return ret;
if (ret) {
}
return 0;
}
The latest upstream 4.15.1 kernel has the fix already, but 4.14.17 doesn't have the fix.