xiaomi-sm8450/android_kernel_xiaomi_sm8450
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Drivers: hv: vmbus: Suspend after cleaning up hv_sock and sub channels

Browse Source 
Before suspend, Linux must make sure all the hv_sock channels have been
properly cleaned up, because a hv_sock connection can not persist across
hibernation, and the user-space app must be properly notified of the
state change of the connection.

Before suspend, Linux also must make sure all the sub-channels have been
destroyed, i.e. the related channel structs of the sub-channels must be
properly removed, otherwise they would cause a conflict when the
sub-channels are recreated upon resume.

Add a counter to track such channels, and vmbus_bus_suspend() should wait
for the counter to drop to zero.

Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
This commit is contained in:
Dexuan Cui
2019-09-05 23:01:21 +00:00
committed by Sasha Levin
parent 1f48dcf180
commit b307b38962
4 changed files with 84 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
drivers/hv/vmbus_drv.c
View File

@@ -2127,7 +2127,8 @@ acpi_walk_err:
static int vmbus_bus_suspend(struct device *dev)
{
struct vmbus_channel *channel;
struct vmbus_channel *channel, *sc;
unsigned long flags;
while (atomic_read(&vmbus_connection.offer_in_progress) != 0) {
/*
@@ -2146,6 +2147,44 @@ static int vmbus_bus_suspend(struct device *dev)
}
mutex_unlock(&vmbus_connection.channel_mutex);
/*
* Wait until all the sub-channels and hv_sock channels have been
* cleaned up. Sub-channels should be destroyed upon suspend, otherwise
* they would conflict with the new sub-channels that will be created
* in the resume path. hv_sock channels should also be destroyed, but
* a hv_sock channel of an established hv_sock connection can not be
* really destroyed since it may still be referenced by the userspace
* application, so we just force the hv_sock channel to be rescinded
* by vmbus_force_channel_rescinded(), and the userspace application
* will thoroughly destroy the channel after hibernation.
*
* Note: the counter nr_chan_close_on_suspend may never go above 0 if
* the VM has no sub-channel and hv_sock channel, e.g. a 1-vCPU VM.
*/
if (atomic_read(&vmbus_connection.nr_chan_close_on_suspend) > 0)
wait_for_completion(&vmbus_connection.ready_for_suspend_event);
mutex_lock(&vmbus_connection.channel_mutex);
list_for_each_entry(channel, &vmbus_connection.chn_list, listentry) {
if (is_hvsock_channel(channel)) {
if (!channel->rescind) {
pr_err("hv_sock channel not rescinded!\n");
WARN_ON_ONCE(1);
}
continue;
}
spin_lock_irqsave(&channel->lock, flags);
list_for_each_entry(sc, &channel->sc_list, sc_list) {
pr_err("Sub-channel not deleted!\n");
WARN_ON_ONCE(1);
}
spin_unlock_irqrestore(&channel->lock, flags);
}
mutex_unlock(&vmbus_connection.channel_mutex);
vmbus_initiate_unload(false);
vmbus_connection.conn_state = DISCONNECTED;
@@ -2186,6 +2225,9 @@ static int vmbus_bus_resume(struct device *dev)
vmbus_request_offers();
/* Reset the event for the next suspend. */
reinit_completion(&vmbus_connection.ready_for_suspend_event);
return 0;
}