2019-05-29 19:57:35 -04:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2009-07-13 19:02:34 -04:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2009, Microsoft Corporation.
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Haiyang Zhang <haiyangz@microsoft.com>
|
|
|
|
* Hank Janssen <hjanssen@microsoft.com>
|
|
|
|
*/
|
2011-03-29 16:58:47 -04:00
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
2009-08-17 20:22:08 -04:00
|
|
|
#include <linux/kernel.h>
|
2016-06-09 21:47:24 -04:00
|
|
|
#include <linux/interrupt.h>
|
2011-02-11 12:59:43 -05:00
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/wait.h>
|
2009-08-17 20:22:08 -04:00
|
|
|
#include <linux/mm.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 04:04:11 -04:00
|
|
|
#include <linux/slab.h>
|
2009-09-11 21:46:44 -04:00
|
|
|
#include <linux/list.h>
|
2010-05-04 18:55:05 -04:00
|
|
|
#include <linux/module.h>
|
2010-05-28 19:22:44 -04:00
|
|
|
#include <linux/completion.h>
|
2016-01-28 01:29:35 -05:00
|
|
|
#include <linux/delay.h>
|
2020-04-05 20:15:12 -04:00
|
|
|
#include <linux/cpu.h>
|
2011-10-04 15:29:52 -04:00
|
|
|
#include <linux/hyperv.h>
|
2017-01-19 13:51:50 -05:00
|
|
|
#include <asm/mshyperv.h>
|
2022-05-27 03:43:59 -04:00
|
|
|
#include <linux/sched/isolation.h>
|
2011-05-12 22:34:15 -04:00
|
|
|
|
2011-05-12 22:34:28 -04:00
|
|
|
#include "hyperv_vmbus.h"
|
2009-07-13 19:02:34 -04:00
|
|
|
|
Drivers: hv: vmbus: Resolve more races involving init_vp_index()
init_vp_index() uses the (per-node) hv_numa_map[] masks to record the
CPUs allocated for channel interrupts at a given time, and distribute
the performance-critical channels across the available CPUs: in part.,
the mask of "candidate" target CPUs in a given NUMA node, for a newly
offered channel, is determined by XOR-ing the node's CPU mask and the
node's hv_numa_map. This operation/mechanism assumes that no offline
CPUs is set in the hv_numa_map mask, an assumption that does not hold
since such mask is currently not updated when a channel is removed or
assigned to a different CPU.
To address the issues described above, this adds hooks in the channel
removal path (hv_process_channel_removal()) and in target_cpu_store()
in order to clear, resp. to update, the hv_numa_map[] masks as needed.
This also adds a (missed) update of the masks in init_vp_index() (cf.,
e.g., the memory-allocation failure path in this function).
Like in the case of init_vp_index(), such hooks require to determine
if the given channel is performance critical. init_vp_index() does
this by parsing the channel's offer, it can not rely on the device
data structure (device_obj) to retrieve such information because the
device data structure has not been allocated/linked with the channel
by the time that init_vp_index() executes. A similar situation may
hold in hv_is_alloced_cpu() (defined below); the adopted approach is
to "cache" the device type of the channel, as computed by parsing the
channel's offer, in the channel structure itself.
Fixes: 7527810573436f ("Drivers: hv: vmbus: Introduce the CHANNELMSG_MODIFYCHANNEL message type")
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200522171901.204127-3-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2020-05-22 13:19:01 -04:00
|
|
|
static void init_vp_index(struct vmbus_channel *channel);
|
2015-12-25 23:00:30 -05:00
|
|
|
|
Drivers: hv: vmbus: Resolve more races involving init_vp_index()
init_vp_index() uses the (per-node) hv_numa_map[] masks to record the
CPUs allocated for channel interrupts at a given time, and distribute
the performance-critical channels across the available CPUs: in part.,
the mask of "candidate" target CPUs in a given NUMA node, for a newly
offered channel, is determined by XOR-ing the node's CPU mask and the
node's hv_numa_map. This operation/mechanism assumes that no offline
CPUs is set in the hv_numa_map mask, an assumption that does not hold
since such mask is currently not updated when a channel is removed or
assigned to a different CPU.
To address the issues described above, this adds hooks in the channel
removal path (hv_process_channel_removal()) and in target_cpu_store()
in order to clear, resp. to update, the hv_numa_map[] masks as needed.
This also adds a (missed) update of the masks in init_vp_index() (cf.,
e.g., the memory-allocation failure path in this function).
Like in the case of init_vp_index(), such hooks require to determine
if the given channel is performance critical. init_vp_index() does
this by parsing the channel's offer, it can not rely on the device
data structure (device_obj) to retrieve such information because the
device data structure has not been allocated/linked with the channel
by the time that init_vp_index() executes. A similar situation may
hold in hv_is_alloced_cpu() (defined below); the adopted approach is
to "cache" the device type of the channel, as computed by parsing the
channel's offer, in the channel structure itself.
Fixes: 7527810573436f ("Drivers: hv: vmbus: Introduce the CHANNELMSG_MODIFYCHANNEL message type")
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200522171901.204127-3-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2020-05-22 13:19:01 -04:00
|
|
|
const struct vmbus_device vmbus_devs[] = {
|
2015-12-25 23:00:30 -05:00
|
|
|
/* IDE */
|
|
|
|
{ .dev_type = HV_IDE,
|
|
|
|
HV_IDE_GUID,
|
|
|
|
.perf_device = true,
|
2021-02-01 09:48:12 -05:00
|
|
|
.allowed_in_isolated = false,
|
2015-12-25 23:00:30 -05:00
|
|
|
},
|
|
|
|
|
|
|
|
/* SCSI */
|
|
|
|
{ .dev_type = HV_SCSI,
|
|
|
|
HV_SCSI_GUID,
|
|
|
|
.perf_device = true,
|
2021-02-01 09:48:12 -05:00
|
|
|
.allowed_in_isolated = true,
|
2015-12-25 23:00:30 -05:00
|
|
|
},
|
|
|
|
|
|
|
|
/* Fibre Channel */
|
|
|
|
{ .dev_type = HV_FC,
|
|
|
|
HV_SYNTHFC_GUID,
|
|
|
|
.perf_device = true,
|
2021-02-01 09:48:12 -05:00
|
|
|
.allowed_in_isolated = false,
|
2015-12-25 23:00:30 -05:00
|
|
|
},
|
|
|
|
|
|
|
|
/* Synthetic NIC */
|
|
|
|
{ .dev_type = HV_NIC,
|
|
|
|
HV_NIC_GUID,
|
|
|
|
.perf_device = true,
|
2021-02-01 09:48:12 -05:00
|
|
|
.allowed_in_isolated = true,
|
2015-12-25 23:00:30 -05:00
|
|
|
},
|
|
|
|
|
|
|
|
/* Network Direct */
|
|
|
|
{ .dev_type = HV_ND,
|
|
|
|
HV_ND_GUID,
|
|
|
|
.perf_device = true,
|
2021-02-01 09:48:12 -05:00
|
|
|
.allowed_in_isolated = false,
|
2015-12-25 23:00:30 -05:00
|
|
|
},
|
|
|
|
|
|
|
|
/* PCIE */
|
|
|
|
{ .dev_type = HV_PCIE,
|
|
|
|
HV_PCIE_GUID,
|
2018-03-27 18:01:02 -04:00
|
|
|
.perf_device = false,
|
2023-03-26 09:52:07 -04:00
|
|
|
.allowed_in_isolated = true,
|
2015-12-25 23:00:30 -05:00
|
|
|
},
|
|
|
|
|
|
|
|
/* Synthetic Frame Buffer */
|
|
|
|
{ .dev_type = HV_FB,
|
|
|
|
HV_SYNTHVID_GUID,
|
|
|
|
.perf_device = false,
|
2021-02-01 09:48:12 -05:00
|
|
|
.allowed_in_isolated = false,
|
2015-12-25 23:00:30 -05:00
|
|
|
},
|
|
|
|
|
|
|
|
/* Synthetic Keyboard */
|
|
|
|
{ .dev_type = HV_KBD,
|
|
|
|
HV_KBD_GUID,
|
|
|
|
.perf_device = false,
|
2021-02-01 09:48:12 -05:00
|
|
|
.allowed_in_isolated = false,
|
2015-12-25 23:00:30 -05:00
|
|
|
},
|
|
|
|
|
|
|
|
/* Synthetic MOUSE */
|
|
|
|
{ .dev_type = HV_MOUSE,
|
|
|
|
HV_MOUSE_GUID,
|
|
|
|
.perf_device = false,
|
2021-02-01 09:48:12 -05:00
|
|
|
.allowed_in_isolated = false,
|
2015-12-25 23:00:30 -05:00
|
|
|
},
|
|
|
|
|
|
|
|
/* KVP */
|
|
|
|
{ .dev_type = HV_KVP,
|
|
|
|
HV_KVP_GUID,
|
|
|
|
.perf_device = false,
|
2021-02-01 09:48:12 -05:00
|
|
|
.allowed_in_isolated = false,
|
2015-12-25 23:00:30 -05:00
|
|
|
},
|
|
|
|
|
|
|
|
/* Time Synch */
|
|
|
|
{ .dev_type = HV_TS,
|
|
|
|
HV_TS_GUID,
|
|
|
|
.perf_device = false,
|
2021-02-01 09:48:12 -05:00
|
|
|
.allowed_in_isolated = true,
|
2015-12-25 23:00:30 -05:00
|
|
|
},
|
|
|
|
|
|
|
|
/* Heartbeat */
|
|
|
|
{ .dev_type = HV_HB,
|
|
|
|
HV_HEART_BEAT_GUID,
|
|
|
|
.perf_device = false,
|
2021-02-01 09:48:12 -05:00
|
|
|
.allowed_in_isolated = true,
|
2015-12-25 23:00:30 -05:00
|
|
|
},
|
|
|
|
|
|
|
|
/* Shutdown */
|
|
|
|
{ .dev_type = HV_SHUTDOWN,
|
|
|
|
HV_SHUTDOWN_GUID,
|
|
|
|
.perf_device = false,
|
2021-02-01 09:48:12 -05:00
|
|
|
.allowed_in_isolated = true,
|
2015-12-25 23:00:30 -05:00
|
|
|
},
|
|
|
|
|
|
|
|
/* File copy */
|
|
|
|
{ .dev_type = HV_FCOPY,
|
|
|
|
HV_FCOPY_GUID,
|
|
|
|
.perf_device = false,
|
2021-02-01 09:48:12 -05:00
|
|
|
.allowed_in_isolated = false,
|
2015-12-25 23:00:30 -05:00
|
|
|
},
|
|
|
|
|
|
|
|
/* Backup */
|
|
|
|
{ .dev_type = HV_BACKUP,
|
|
|
|
HV_VSS_GUID,
|
|
|
|
.perf_device = false,
|
2021-02-01 09:48:12 -05:00
|
|
|
.allowed_in_isolated = false,
|
2015-12-25 23:00:30 -05:00
|
|
|
},
|
|
|
|
|
|
|
|
/* Dynamic Memory */
|
|
|
|
{ .dev_type = HV_DM,
|
|
|
|
HV_DM_GUID,
|
|
|
|
.perf_device = false,
|
2021-02-01 09:48:12 -05:00
|
|
|
.allowed_in_isolated = false,
|
2015-12-25 23:00:30 -05:00
|
|
|
},
|
|
|
|
|
|
|
|
/* Unknown GUID */
|
2016-12-03 15:34:29 -05:00
|
|
|
{ .dev_type = HV_UNKNOWN,
|
2015-12-25 23:00:30 -05:00
|
|
|
.perf_device = false,
|
2021-02-01 09:48:12 -05:00
|
|
|
.allowed_in_isolated = false,
|
2015-12-25 23:00:30 -05:00
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2016-09-07 08:39:34 -04:00
|
|
|
static const struct {
|
2019-01-10 09:25:32 -05:00
|
|
|
guid_t guid;
|
2016-09-07 08:39:34 -04:00
|
|
|
} vmbus_unsupported_devs[] = {
|
|
|
|
{ HV_AVMA1_GUID },
|
|
|
|
{ HV_AVMA2_GUID },
|
|
|
|
{ HV_RDV_GUID },
|
2022-04-12 22:49:00 -04:00
|
|
|
{ HV_IMC_GUID },
|
2016-09-07 08:39:34 -04:00
|
|
|
};
|
|
|
|
|
2016-12-22 19:54:00 -05:00
|
|
|
/*
|
|
|
|
* The rescinded channel may be blocked waiting for a response from the host;
|
|
|
|
* take care of that.
|
|
|
|
*/
|
|
|
|
static void vmbus_rescind_cleanup(struct vmbus_channel *channel)
|
|
|
|
{
|
|
|
|
struct vmbus_channel_msginfo *msginfo;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
|
|
|
|
spin_lock_irqsave(&vmbus_connection.channelmsg_lock, flags);
|
2017-09-30 00:09:36 -04:00
|
|
|
channel->rescind = true;
|
2016-12-22 19:54:00 -05:00
|
|
|
list_for_each_entry(msginfo, &vmbus_connection.chn_msg_list,
|
|
|
|
msglistentry) {
|
|
|
|
|
|
|
|
if (msginfo->waiting_channel == channel) {
|
|
|
|
complete(&msginfo->waitevent);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
spin_unlock_irqrestore(&vmbus_connection.channelmsg_lock, flags);
|
|
|
|
}
|
|
|
|
|
2019-01-10 09:25:32 -05:00
|
|
|
static bool is_unsupported_vmbus_devs(const guid_t *guid)
|
2016-09-07 08:39:34 -04:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(vmbus_unsupported_devs); i++)
|
2019-01-10 09:25:32 -05:00
|
|
|
if (guid_equal(guid, &vmbus_unsupported_devs[i].guid))
|
2016-09-07 08:39:34 -04:00
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static u16 hv_get_dev_type(const struct vmbus_channel *channel)
|
2015-12-25 23:00:30 -05:00
|
|
|
{
|
2019-01-10 09:25:32 -05:00
|
|
|
const guid_t *guid = &channel->offermsg.offer.if_type;
|
2015-12-25 23:00:30 -05:00
|
|
|
u16 i;
|
|
|
|
|
2016-09-07 08:39:34 -04:00
|
|
|
if (is_hvsock_channel(channel) || is_unsupported_vmbus_devs(guid))
|
2016-12-03 15:34:29 -05:00
|
|
|
return HV_UNKNOWN;
|
2016-09-07 08:39:34 -04:00
|
|
|
|
2016-12-03 15:34:29 -05:00
|
|
|
for (i = HV_IDE; i < HV_UNKNOWN; i++) {
|
2019-01-10 09:25:32 -05:00
|
|
|
if (guid_equal(guid, &vmbus_devs[i].guid))
|
2015-12-25 23:00:30 -05:00
|
|
|
return i;
|
|
|
|
}
|
|
|
|
pr_info("Unknown GUID: %pUl\n", guid);
|
|
|
|
return i;
|
|
|
|
}
|
2015-05-06 20:47:45 -04:00
|
|
|
|
2010-05-04 18:55:05 -04:00
|
|
|
/**
|
2018-09-23 17:10:41 -04:00
|
|
|
* vmbus_prep_negotiate_resp() - Create default response for Negotiate message
|
2010-05-04 18:55:05 -04:00
|
|
|
* @icmsghdrp: Pointer to msg header structure
|
|
|
|
* @buf: Raw buffer channel data
|
2020-11-09 05:07:04 -05:00
|
|
|
* @buflen: Length of the raw buffer channel data.
|
2018-09-23 17:10:41 -04:00
|
|
|
* @fw_version: The framework versions we can support.
|
|
|
|
* @fw_vercnt: The size of @fw_version.
|
|
|
|
* @srv_version: The service versions we can support.
|
|
|
|
* @srv_vercnt: The size of @srv_version.
|
|
|
|
* @nego_fw_version: The selected framework version.
|
|
|
|
* @nego_srv_version: The selected service version.
|
2010-05-04 18:55:05 -04:00
|
|
|
*
|
2018-09-23 17:10:41 -04:00
|
|
|
* Note: Versions are given in decreasing order.
|
2010-05-04 18:55:05 -04:00
|
|
|
*
|
2018-09-23 17:10:41 -04:00
|
|
|
* Set up and fill in default negotiate response message.
|
2010-05-04 18:55:05 -04:00
|
|
|
* Mainly used by Hyper-V drivers.
|
|
|
|
*/
|
2020-11-09 05:07:04 -05:00
|
|
|
bool vmbus_prep_negotiate_resp(struct icmsg_hdr *icmsghdrp, u8 *buf,
|
|
|
|
u32 buflen, const int *fw_version, int fw_vercnt,
|
2017-01-28 14:37:17 -05:00
|
|
|
const int *srv_version, int srv_vercnt,
|
|
|
|
int *nego_fw_version, int *nego_srv_version)
|
2010-05-04 18:55:05 -04:00
|
|
|
{
|
2013-07-02 13:31:30 -04:00
|
|
|
int icframe_major, icframe_minor;
|
|
|
|
int icmsg_major, icmsg_minor;
|
|
|
|
int fw_major, fw_minor;
|
|
|
|
int srv_major, srv_minor;
|
2017-01-28 14:37:17 -05:00
|
|
|
int i, j;
|
2013-07-02 13:31:30 -04:00
|
|
|
bool found_match = false;
|
2017-01-28 14:37:17 -05:00
|
|
|
struct icmsg_negotiate *negop;
|
2012-05-12 16:44:58 -04:00
|
|
|
|
2020-11-09 05:07:04 -05:00
|
|
|
/* Check that there's enough space for icframe_vercnt, icmsg_vercnt */
|
|
|
|
if (buflen < ICMSG_HDR + offsetof(struct icmsg_negotiate, reserved)) {
|
|
|
|
pr_err_ratelimited("Invalid icmsg negotiate\n");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2012-05-12 16:44:57 -04:00
|
|
|
icmsghdrp->icmsgsize = 0x10;
|
2020-11-09 05:07:04 -05:00
|
|
|
negop = (struct icmsg_negotiate *)&buf[ICMSG_HDR];
|
2010-05-04 18:55:05 -04:00
|
|
|
|
2013-07-02 13:31:30 -04:00
|
|
|
icframe_major = negop->icframe_vercnt;
|
|
|
|
icframe_minor = 0;
|
|
|
|
|
|
|
|
icmsg_major = negop->icmsg_vercnt;
|
|
|
|
icmsg_minor = 0;
|
2012-05-12 16:44:58 -04:00
|
|
|
|
2020-11-09 05:07:04 -05:00
|
|
|
/* Validate negop packet */
|
|
|
|
if (icframe_major > IC_VERSION_NEGOTIATION_MAX_VER_COUNT ||
|
|
|
|
icmsg_major > IC_VERSION_NEGOTIATION_MAX_VER_COUNT ||
|
|
|
|
ICMSG_NEGOTIATE_PKT_SIZE(icframe_major, icmsg_major) > buflen) {
|
|
|
|
pr_err_ratelimited("Invalid icmsg negotiate - icframe_major: %u, icmsg_major: %u\n",
|
|
|
|
icframe_major, icmsg_major);
|
|
|
|
goto fw_error;
|
|
|
|
}
|
|
|
|
|
2012-05-12 16:44:58 -04:00
|
|
|
/*
|
|
|
|
* Select the framework version number we will
|
|
|
|
* support.
|
|
|
|
*/
|
|
|
|
|
2017-01-28 14:37:17 -05:00
|
|
|
for (i = 0; i < fw_vercnt; i++) {
|
|
|
|
fw_major = (fw_version[i] >> 16);
|
|
|
|
fw_minor = (fw_version[i] & 0xFFFF);
|
|
|
|
|
|
|
|
for (j = 0; j < negop->icframe_vercnt; j++) {
|
|
|
|
if ((negop->icversion_data[j].major == fw_major) &&
|
|
|
|
(negop->icversion_data[j].minor == fw_minor)) {
|
|
|
|
icframe_major = negop->icversion_data[j].major;
|
|
|
|
icframe_minor = negop->icversion_data[j].minor;
|
|
|
|
found_match = true;
|
|
|
|
break;
|
|
|
|
}
|
2013-07-02 13:31:30 -04:00
|
|
|
}
|
2017-01-28 14:37:17 -05:00
|
|
|
|
|
|
|
if (found_match)
|
|
|
|
break;
|
2012-05-12 16:44:58 -04:00
|
|
|
}
|
|
|
|
|
2013-07-02 13:31:30 -04:00
|
|
|
if (!found_match)
|
|
|
|
goto fw_error;
|
|
|
|
|
|
|
|
found_match = false;
|
|
|
|
|
2017-01-28 14:37:17 -05:00
|
|
|
for (i = 0; i < srv_vercnt; i++) {
|
|
|
|
srv_major = (srv_version[i] >> 16);
|
|
|
|
srv_minor = (srv_version[i] & 0xFFFF);
|
|
|
|
|
|
|
|
for (j = negop->icframe_vercnt;
|
|
|
|
(j < negop->icframe_vercnt + negop->icmsg_vercnt);
|
|
|
|
j++) {
|
|
|
|
|
|
|
|
if ((negop->icversion_data[j].major == srv_major) &&
|
|
|
|
(negop->icversion_data[j].minor == srv_minor)) {
|
|
|
|
|
|
|
|
icmsg_major = negop->icversion_data[j].major;
|
|
|
|
icmsg_minor = negop->icversion_data[j].minor;
|
|
|
|
found_match = true;
|
|
|
|
break;
|
|
|
|
}
|
2013-07-02 13:31:30 -04:00
|
|
|
}
|
2017-01-28 14:37:17 -05:00
|
|
|
|
|
|
|
if (found_match)
|
|
|
|
break;
|
2010-05-04 18:55:05 -04:00
|
|
|
}
|
2012-05-12 16:44:57 -04:00
|
|
|
|
2012-05-12 16:44:58 -04:00
|
|
|
/*
|
2013-07-02 13:31:30 -04:00
|
|
|
* Respond with the framework and service
|
2012-05-12 16:44:58 -04:00
|
|
|
* version numbers we can support.
|
|
|
|
*/
|
2013-07-02 13:31:30 -04:00
|
|
|
|
|
|
|
fw_error:
|
|
|
|
if (!found_match) {
|
|
|
|
negop->icframe_vercnt = 0;
|
|
|
|
negop->icmsg_vercnt = 0;
|
|
|
|
} else {
|
|
|
|
negop->icframe_vercnt = 1;
|
|
|
|
negop->icmsg_vercnt = 1;
|
|
|
|
}
|
|
|
|
|
2017-01-28 14:37:17 -05:00
|
|
|
if (nego_fw_version)
|
|
|
|
*nego_fw_version = (icframe_major << 16) | icframe_minor;
|
|
|
|
|
|
|
|
if (nego_srv_version)
|
|
|
|
*nego_srv_version = (icmsg_major << 16) | icmsg_minor;
|
|
|
|
|
2013-07-02 13:31:30 -04:00
|
|
|
negop->icversion_data[0].major = icframe_major;
|
|
|
|
negop->icversion_data[0].minor = icframe_minor;
|
|
|
|
negop->icversion_data[1].major = icmsg_major;
|
|
|
|
negop->icversion_data[1].minor = icmsg_minor;
|
|
|
|
return found_match;
|
2010-05-04 18:55:05 -04:00
|
|
|
}
|
2011-10-11 10:42:28 -04:00
|
|
|
EXPORT_SYMBOL_GPL(vmbus_prep_negotiate_resp);
|
2010-05-04 18:55:05 -04:00
|
|
|
|
2010-03-04 17:11:00 -05:00
|
|
|
/*
|
2010-10-15 13:14:07 -04:00
|
|
|
* alloc_channel - Allocate and initialize a vmbus channel object
|
2009-09-01 00:47:21 -04:00
|
|
|
*/
|
2010-10-20 18:51:57 -04:00
|
|
|
static struct vmbus_channel *alloc_channel(void)
|
2009-07-13 19:02:34 -04:00
|
|
|
{
|
2009-08-18 18:21:19 -04:00
|
|
|
struct vmbus_channel *channel;
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2009-08-18 18:21:19 -04:00
|
|
|
channel = kzalloc(sizeof(*channel), GFP_ATOMIC);
|
2009-07-13 19:02:34 -04:00
|
|
|
if (!channel)
|
|
|
|
return NULL;
|
|
|
|
|
2020-04-05 20:15:09 -04:00
|
|
|
spin_lock_init(&channel->sched_lock);
|
2017-11-14 08:53:33 -05:00
|
|
|
init_completion(&channel->rescind_event);
|
2013-05-23 15:02:32 -04:00
|
|
|
|
|
|
|
INIT_LIST_HEAD(&channel->sc_list);
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2017-02-12 01:02:20 -05:00
|
|
|
tasklet_init(&channel->callback_event,
|
|
|
|
vmbus_on_event, (unsigned long)channel);
|
|
|
|
|
2019-03-14 16:05:15 -04:00
|
|
|
hv_ringbuffer_pre_init(channel);
|
|
|
|
|
2009-07-13 19:02:34 -04:00
|
|
|
return channel;
|
|
|
|
}
|
|
|
|
|
2010-03-04 17:11:00 -05:00
|
|
|
/*
|
2010-10-15 13:14:07 -04:00
|
|
|
* free_channel - Release the resources used by the vmbus channel object
|
2009-09-01 00:47:21 -04:00
|
|
|
*/
|
2011-10-11 11:40:01 -04:00
|
|
|
static void free_channel(struct vmbus_channel *channel)
|
2009-07-13 19:02:34 -04:00
|
|
|
{
|
2017-02-12 01:02:20 -05:00
|
|
|
tasklet_kill(&channel->callback_event);
|
2019-03-19 00:04:01 -04:00
|
|
|
vmbus_remove_channel_attr_group(channel);
|
2017-03-04 20:13:57 -05:00
|
|
|
|
2017-09-21 23:58:49 -04:00
|
|
|
kobject_put(&channel->kobj);
|
2009-07-13 19:02:34 -04:00
|
|
|
}
|
|
|
|
|
2020-04-05 20:15:06 -04:00
|
|
|
void vmbus_channel_map_relid(struct vmbus_channel *channel)
|
2014-04-08 21:45:54 -04:00
|
|
|
{
|
2020-04-05 20:15:06 -04:00
|
|
|
if (WARN_ON(channel->offermsg.child_relid >= MAX_CHANNEL_RELIDS))
|
|
|
|
return;
|
|
|
|
/*
|
|
|
|
* The mapping of the channel's relid is visible from the CPUs that
|
|
|
|
* execute vmbus_chan_sched() by the time that vmbus_chan_sched() will
|
|
|
|
* execute:
|
|
|
|
*
|
|
|
|
* (a) In the "normal (i.e., not resuming from hibernation)" path,
|
2022-03-28 11:44:57 -04:00
|
|
|
* the full barrier in virt_store_mb() guarantees that the store
|
2020-04-05 20:15:06 -04:00
|
|
|
* is propagated to all CPUs before the add_channel_work work
|
|
|
|
* is queued. In turn, add_channel_work is queued before the
|
|
|
|
* channel's ring buffer is allocated/initialized and the
|
|
|
|
* OPENCHANNEL message for the channel is sent in vmbus_open().
|
|
|
|
* Hyper-V won't start sending the interrupts for the channel
|
|
|
|
* before the OPENCHANNEL message is acked. The memory barrier
|
|
|
|
* in vmbus_chan_sched() -> sync_test_and_clear_bit() ensures
|
|
|
|
* that vmbus_chan_sched() must find the channel's relid in
|
|
|
|
* recv_int_page before retrieving the channel pointer from the
|
|
|
|
* array of channels.
|
|
|
|
*
|
2022-03-28 11:44:57 -04:00
|
|
|
* (b) In the "resuming from hibernation" path, the virt_store_mb()
|
2020-04-05 20:15:06 -04:00
|
|
|
* guarantees that the store is propagated to all CPUs before
|
|
|
|
* the VMBus connection is marked as ready for the resume event
|
|
|
|
* (cf. check_ready_for_resume_event()). The interrupt handler
|
|
|
|
* of the VMBus driver and vmbus_chan_sched() can not run before
|
|
|
|
* vmbus_bus_resume() has completed execution (cf. resume_noirq).
|
|
|
|
*/
|
2022-03-28 11:44:57 -04:00
|
|
|
virt_store_mb(
|
2020-04-05 20:15:06 -04:00
|
|
|
vmbus_connection.channels[channel->offermsg.child_relid],
|
|
|
|
channel);
|
2014-04-08 21:45:54 -04:00
|
|
|
}
|
2010-05-28 19:22:44 -04:00
|
|
|
|
2020-04-05 20:15:06 -04:00
|
|
|
void vmbus_channel_unmap_relid(struct vmbus_channel *channel)
|
2014-04-08 21:45:54 -04:00
|
|
|
{
|
2020-04-05 20:15:06 -04:00
|
|
|
if (WARN_ON(channel->offermsg.child_relid >= MAX_CHANNEL_RELIDS))
|
|
|
|
return;
|
|
|
|
WRITE_ONCE(
|
|
|
|
vmbus_connection.channels[channel->offermsg.child_relid],
|
|
|
|
NULL);
|
2014-04-08 21:45:54 -04:00
|
|
|
}
|
2010-05-28 19:22:44 -04:00
|
|
|
|
2015-12-14 19:01:50 -05:00
|
|
|
static void vmbus_release_relid(u32 relid)
|
2010-12-15 13:48:09 -05:00
|
|
|
{
|
2015-02-28 14:18:17 -05:00
|
|
|
struct vmbus_channel_relid_released msg;
|
2017-10-29 15:21:14 -04:00
|
|
|
int ret;
|
2010-12-15 13:48:09 -05:00
|
|
|
|
2013-03-15 15:25:44 -04:00
|
|
|
memset(&msg, 0, sizeof(struct vmbus_channel_relid_released));
|
2015-02-28 14:18:17 -05:00
|
|
|
msg.child_relid = relid;
|
2013-03-15 15:25:44 -04:00
|
|
|
msg.header.msgtype = CHANNELMSG_RELID_RELEASED;
|
2017-10-29 15:21:14 -04:00
|
|
|
ret = vmbus_post_msg(&msg, sizeof(struct vmbus_channel_relid_released),
|
|
|
|
true);
|
|
|
|
|
|
|
|
trace_vmbus_release_relid(&msg, ret);
|
2015-12-14 19:01:50 -05:00
|
|
|
}
|
2013-03-15 15:25:44 -04:00
|
|
|
|
2018-09-14 12:10:15 -04:00
|
|
|
void hv_process_channel_removal(struct vmbus_channel *channel)
|
2015-12-14 19:01:50 -05:00
|
|
|
{
|
2020-04-05 20:15:06 -04:00
|
|
|
lockdep_assert_held(&vmbus_connection.channel_mutex);
|
2017-09-30 00:09:36 -04:00
|
|
|
BUG_ON(!channel->rescind);
|
2018-09-14 12:10:15 -04:00
|
|
|
|
2020-04-05 20:15:06 -04:00
|
|
|
/*
|
|
|
|
* hv_process_channel_removal() could find INVALID_RELID only for
|
|
|
|
* hv_sock channels. See the inline comments in vmbus_onoffer().
|
|
|
|
*/
|
|
|
|
WARN_ON(channel->offermsg.child_relid == INVALID_RELID &&
|
|
|
|
!is_hvsock_channel(channel));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Upon suspend, an in-use hv_sock channel is removed from the array of
|
|
|
|
* channels and the relid is invalidated. After hibernation, when the
|
2022-05-21 07:11:10 -04:00
|
|
|
* user-space application destroys the channel, it's unnecessary and
|
2020-04-05 20:15:06 -04:00
|
|
|
* unsafe to remove the channel from the array of channels. See also
|
|
|
|
* the inline comments before the call of vmbus_release_relid() below.
|
|
|
|
*/
|
|
|
|
if (channel->offermsg.child_relid != INVALID_RELID)
|
|
|
|
vmbus_channel_unmap_relid(channel);
|
2014-04-08 21:45:54 -04:00
|
|
|
|
2020-06-17 12:46:40 -04:00
|
|
|
if (channel->primary_channel == NULL)
|
2013-05-23 15:02:32 -04:00
|
|
|
list_del(&channel->listentry);
|
2020-06-17 12:46:40 -04:00
|
|
|
else
|
2013-10-16 22:27:19 -04:00
|
|
|
list_del(&channel->sc_list);
|
2015-08-13 20:07:03 -04:00
|
|
|
|
Drivers: hv: vmbus: Resolve more races involving init_vp_index()
init_vp_index() uses the (per-node) hv_numa_map[] masks to record the
CPUs allocated for channel interrupts at a given time, and distribute
the performance-critical channels across the available CPUs: in part.,
the mask of "candidate" target CPUs in a given NUMA node, for a newly
offered channel, is determined by XOR-ing the node's CPU mask and the
node's hv_numa_map. This operation/mechanism assumes that no offline
CPUs is set in the hv_numa_map mask, an assumption that does not hold
since such mask is currently not updated when a channel is removed or
assigned to a different CPU.
To address the issues described above, this adds hooks in the channel
removal path (hv_process_channel_removal()) and in target_cpu_store()
in order to clear, resp. to update, the hv_numa_map[] masks as needed.
This also adds a (missed) update of the masks in init_vp_index() (cf.,
e.g., the memory-allocation failure path in this function).
Like in the case of init_vp_index(), such hooks require to determine
if the given channel is performance critical. init_vp_index() does
this by parsing the channel's offer, it can not rely on the device
data structure (device_obj) to retrieve such information because the
device data structure has not been allocated/linked with the channel
by the time that init_vp_index() executes. A similar situation may
hold in hv_is_alloced_cpu() (defined below); the adopted approach is
to "cache" the device type of the channel, as computed by parsing the
channel's offer, in the channel structure itself.
Fixes: 7527810573436f ("Drivers: hv: vmbus: Introduce the CHANNELMSG_MODIFYCHANNEL message type")
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200522171901.204127-3-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2020-05-22 13:19:01 -04:00
|
|
|
/*
|
|
|
|
* If this is a "perf" channel, updates the hv_numa_map[] masks so that
|
|
|
|
* init_vp_index() can (re-)use the CPU.
|
|
|
|
*/
|
|
|
|
if (hv_is_perf_channel(channel))
|
2022-01-28 05:34:11 -05:00
|
|
|
hv_clear_allocated_cpu(channel->target_cpu);
|
Drivers: hv: vmbus: Resolve more races involving init_vp_index()
init_vp_index() uses the (per-node) hv_numa_map[] masks to record the
CPUs allocated for channel interrupts at a given time, and distribute
the performance-critical channels across the available CPUs: in part.,
the mask of "candidate" target CPUs in a given NUMA node, for a newly
offered channel, is determined by XOR-ing the node's CPU mask and the
node's hv_numa_map. This operation/mechanism assumes that no offline
CPUs is set in the hv_numa_map mask, an assumption that does not hold
since such mask is currently not updated when a channel is removed or
assigned to a different CPU.
To address the issues described above, this adds hooks in the channel
removal path (hv_process_channel_removal()) and in target_cpu_store()
in order to clear, resp. to update, the hv_numa_map[] masks as needed.
This also adds a (missed) update of the masks in init_vp_index() (cf.,
e.g., the memory-allocation failure path in this function).
Like in the case of init_vp_index(), such hooks require to determine
if the given channel is performance critical. init_vp_index() does
this by parsing the channel's offer, it can not rely on the device
data structure (device_obj) to retrieve such information because the
device data structure has not been allocated/linked with the channel
by the time that init_vp_index() executes. A similar situation may
hold in hv_is_alloced_cpu() (defined below); the adopted approach is
to "cache" the device type of the channel, as computed by parsing the
channel's offer, in the channel structure itself.
Fixes: 7527810573436f ("Drivers: hv: vmbus: Introduce the CHANNELMSG_MODIFYCHANNEL message type")
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200522171901.204127-3-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2020-05-22 13:19:01 -04:00
|
|
|
|
2019-09-05 19:01:22 -04:00
|
|
|
/*
|
|
|
|
* Upon suspend, an in-use hv_sock channel is marked as "rescinded" and
|
|
|
|
* the relid is invalidated; after hibernation, when the user-space app
|
|
|
|
* destroys the channel, the relid is INVALID_RELID, and in this case
|
|
|
|
* it's unnecessary and unsafe to release the old relid, since the same
|
|
|
|
* relid can refer to a completely different channel now.
|
|
|
|
*/
|
|
|
|
if (channel->offermsg.child_relid != INVALID_RELID)
|
|
|
|
vmbus_release_relid(channel->offermsg.child_relid);
|
2016-06-09 21:47:24 -04:00
|
|
|
|
2013-03-15 15:25:44 -04:00
|
|
|
free_channel(channel);
|
2010-12-15 13:48:09 -05:00
|
|
|
}
|
2010-05-28 19:22:44 -04:00
|
|
|
|
2011-12-12 12:29:17 -05:00
|
|
|
void vmbus_free_channels(void)
|
|
|
|
{
|
2015-04-23 00:31:30 -04:00
|
|
|
struct vmbus_channel *channel, *tmp;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(channel, tmp, &vmbus_connection.chn_list,
|
|
|
|
listentry) {
|
Drivers: hv: vmbus: fix rescind-offer handling for device without a driver
In the path vmbus_onoffer_rescind() -> vmbus_device_unregister() ->
device_unregister() -> ... -> __device_release_driver(), we can see for a
device without a driver loaded: dev->driver is NULL, so
dev->bus->remove(dev), namely vmbus_remove(), isn't invoked.
As a result, vmbus_remove() -> hv_process_channel_removal() isn't invoked
and some cleanups(like sending a CHANNELMSG_RELID_RELEASED message to the
host) aren't done.
We can demo the issue this way:
1. rmmod hv_utils;
2. disable the Heartbeat Integration Service in Hyper-V Manager and lsvmbus
shows the device disappears.
3. re-enable the Heartbeat in Hyper-V Manager and modprobe hv_utils, but
lsvmbus shows the device can't appear again.
This is because, the host thinks the VM hasn't released the relid, so can't
re-offer the device to the VM.
We can fix the issue by moving hv_process_channel_removal()
from vmbus_close_internal() to vmbus_device_release(), since the latter is
always invoked on device_unregister(), whether or not the dev has a driver
loaded.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-14 19:01:49 -05:00
|
|
|
/* hv_process_channel_removal() needs this */
|
2015-04-23 00:31:30 -04:00
|
|
|
channel->rescind = true;
|
2011-12-12 12:29:17 -05:00
|
|
|
|
|
|
|
vmbus_device_unregister(channel->device_obj);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Drivers: hv: vmbus: Offload the handling of channels to two workqueues
vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.
The above is also true for primary channels, if the related device
drivers use sync probing mode by default.
And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.
The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).
The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.
So actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.
Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-02 19:54:35 -05:00
|
|
|
/* Note: the function can run concurrently for primary/sub channels. */
|
|
|
|
static void vmbus_add_channel_work(struct work_struct *work)
|
2009-07-13 19:02:34 -04:00
|
|
|
{
|
Drivers: hv: vmbus: Offload the handling of channels to two workqueues
vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.
The above is also true for primary channels, if the related device
drivers use sync probing mode by default.
And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.
The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).
The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.
So actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.
Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-02 19:54:35 -05:00
|
|
|
struct vmbus_channel *newchannel =
|
|
|
|
container_of(work, struct vmbus_channel, add_channel_work);
|
|
|
|
struct vmbus_channel *primary_channel = newchannel->primary_channel;
|
2016-01-28 01:29:43 -05:00
|
|
|
int ret;
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2013-08-26 17:08:58 -04:00
|
|
|
/*
|
|
|
|
* This state is used to indicate a successful open
|
|
|
|
* so that when we do close the channel normally, we
|
Drivers: hv: vmbus: Offload the handling of channels to two workqueues
vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.
The above is also true for primary channels, if the related device
drivers use sync probing mode by default.
And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.
The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).
The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.
So actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.
Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-02 19:54:35 -05:00
|
|
|
* can cleanup properly.
|
2013-08-26 17:08:58 -04:00
|
|
|
*/
|
|
|
|
newchannel->state = CHANNEL_OPEN_STATE;
|
|
|
|
|
Drivers: hv: vmbus: Offload the handling of channels to two workqueues
vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.
The above is also true for primary channels, if the related device
drivers use sync probing mode by default.
And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.
The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).
The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.
So actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.
Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-02 19:54:35 -05:00
|
|
|
if (primary_channel != NULL) {
|
|
|
|
/* newchannel is a sub-channel. */
|
|
|
|
struct hv_device *dev = primary_channel->device_obj;
|
2017-09-21 23:58:49 -04:00
|
|
|
|
2018-06-05 16:37:52 -04:00
|
|
|
if (vmbus_add_channel_kobj(dev, newchannel))
|
Drivers: hv: vmbus: Offload the handling of channels to two workqueues
vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.
The above is also true for primary channels, if the related device
drivers use sync probing mode by default.
And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.
The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).
The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.
So actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.
Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-02 19:54:35 -05:00
|
|
|
goto err_deq_chan;
|
|
|
|
|
|
|
|
if (primary_channel->sc_creation_callback != NULL)
|
|
|
|
primary_channel->sc_creation_callback(newchannel);
|
2017-09-21 23:58:49 -04:00
|
|
|
|
2017-09-30 00:09:36 -04:00
|
|
|
newchannel->probe_done = true;
|
2015-05-06 20:47:42 -04:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2009-09-01 00:47:21 -04:00
|
|
|
/*
|
Drivers: hv: vmbus: Offload the handling of channels to two workqueues
vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.
The above is also true for primary channels, if the related device
drivers use sync probing mode by default.
And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.
The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).
The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.
So actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.
Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-02 19:54:35 -05:00
|
|
|
* Start the process of binding the primary channel to the driver
|
2009-09-01 00:47:21 -04:00
|
|
|
*/
|
2011-09-08 10:24:12 -04:00
|
|
|
newchannel->device_obj = vmbus_device_create(
|
2011-01-26 15:12:12 -05:00
|
|
|
&newchannel->offermsg.offer.if_type,
|
|
|
|
&newchannel->offermsg.offer.if_instance,
|
2010-10-15 13:14:06 -04:00
|
|
|
newchannel);
|
2015-01-20 10:45:04 -05:00
|
|
|
if (!newchannel->device_obj)
|
2015-02-28 14:18:19 -05:00
|
|
|
goto err_deq_chan;
|
2009-07-13 19:02:34 -04:00
|
|
|
|
Drivers: hv: vmbus: Resolve more races involving init_vp_index()
init_vp_index() uses the (per-node) hv_numa_map[] masks to record the
CPUs allocated for channel interrupts at a given time, and distribute
the performance-critical channels across the available CPUs: in part.,
the mask of "candidate" target CPUs in a given NUMA node, for a newly
offered channel, is determined by XOR-ing the node's CPU mask and the
node's hv_numa_map. This operation/mechanism assumes that no offline
CPUs is set in the hv_numa_map mask, an assumption that does not hold
since such mask is currently not updated when a channel is removed or
assigned to a different CPU.
To address the issues described above, this adds hooks in the channel
removal path (hv_process_channel_removal()) and in target_cpu_store()
in order to clear, resp. to update, the hv_numa_map[] masks as needed.
This also adds a (missed) update of the masks in init_vp_index() (cf.,
e.g., the memory-allocation failure path in this function).
Like in the case of init_vp_index(), such hooks require to determine
if the given channel is performance critical. init_vp_index() does
this by parsing the channel's offer, it can not rely on the device
data structure (device_obj) to retrieve such information because the
device data structure has not been allocated/linked with the channel
by the time that init_vp_index() executes. A similar situation may
hold in hv_is_alloced_cpu() (defined below); the adopted approach is
to "cache" the device type of the channel, as computed by parsing the
channel's offer, in the channel structure itself.
Fixes: 7527810573436f ("Drivers: hv: vmbus: Introduce the CHANNELMSG_MODIFYCHANNEL message type")
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200522171901.204127-3-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2020-05-22 13:19:01 -04:00
|
|
|
newchannel->device_obj->device_id = newchannel->device_id;
|
2009-07-27 16:47:24 -04:00
|
|
|
/*
|
|
|
|
* Add the new device to the bus. This will kick off device-driver
|
|
|
|
* binding which eventually invokes the device driver's AddDevice()
|
|
|
|
* method.
|
2022-11-19 03:11:34 -05:00
|
|
|
*
|
|
|
|
* If vmbus_device_register() fails, the 'device_obj' is freed in
|
|
|
|
* vmbus_device_release() as called by device_unregister() in the
|
|
|
|
* error path of vmbus_device_register(). In the outside error
|
|
|
|
* path, there's no need to free it.
|
2009-07-27 16:47:24 -04:00
|
|
|
*/
|
2016-01-28 01:29:43 -05:00
|
|
|
ret = vmbus_device_register(newchannel->device_obj);
|
|
|
|
|
|
|
|
if (ret != 0) {
|
2015-03-27 12:10:09 -04:00
|
|
|
pr_err("unable to add child device object (relid %d)\n",
|
|
|
|
newchannel->offermsg.child_relid);
|
|
|
|
goto err_deq_chan;
|
|
|
|
}
|
2017-04-30 19:21:18 -04:00
|
|
|
|
2017-08-11 13:03:59 -04:00
|
|
|
newchannel->probe_done = true;
|
2015-01-20 10:45:04 -05:00
|
|
|
return;
|
2015-02-28 14:18:18 -05:00
|
|
|
|
2015-02-28 14:18:19 -05:00
|
|
|
err_deq_chan:
|
2015-12-14 19:01:51 -05:00
|
|
|
mutex_lock(&vmbus_connection.channel_mutex);
|
Drivers: hv: vmbus: Offload the handling of channels to two workqueues
vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.
The above is also true for primary channels, if the related device
drivers use sync probing mode by default.
And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.
The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).
The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.
So actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.
Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-02 19:54:35 -05:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We need to set the flag, otherwise
|
|
|
|
* vmbus_onoffer_rescind() can be blocked.
|
|
|
|
*/
|
|
|
|
newchannel->probe_done = true;
|
|
|
|
|
2020-06-17 12:46:40 -04:00
|
|
|
if (primary_channel == NULL)
|
Drivers: hv: vmbus: Offload the handling of channels to two workqueues
vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.
The above is also true for primary channels, if the related device
drivers use sync probing mode by default.
And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.
The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).
The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.
So actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.
Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-02 19:54:35 -05:00
|
|
|
list_del(&newchannel->listentry);
|
2020-06-17 12:46:40 -04:00
|
|
|
else
|
Drivers: hv: vmbus: Offload the handling of channels to two workqueues
vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.
The above is also true for primary channels, if the related device
drivers use sync probing mode by default.
And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.
The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).
The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.
So actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.
Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-02 19:54:35 -05:00
|
|
|
list_del(&newchannel->sc_list);
|
|
|
|
|
2020-04-05 20:15:06 -04:00
|
|
|
/* vmbus_process_offer() has mapped the channel. */
|
|
|
|
vmbus_channel_unmap_relid(newchannel);
|
2015-02-28 14:18:19 -05:00
|
|
|
|
2020-04-05 20:15:06 -04:00
|
|
|
mutex_unlock(&vmbus_connection.channel_mutex);
|
2016-06-09 21:47:24 -04:00
|
|
|
|
|
|
|
vmbus_release_relid(newchannel->offermsg.child_relid);
|
2015-02-28 14:18:19 -05:00
|
|
|
|
2015-01-20 10:45:04 -05:00
|
|
|
free_channel(newchannel);
|
2009-07-13 19:02:34 -04:00
|
|
|
}
|
|
|
|
|
Drivers: hv: vmbus: Offload the handling of channels to two workqueues
vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.
The above is also true for primary channels, if the related device
drivers use sync probing mode by default.
And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.
The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).
The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.
So actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.
Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-02 19:54:35 -05:00
|
|
|
/*
|
|
|
|
* vmbus_process_offer - Process the offer by creating a channel/device
|
|
|
|
* associated with this offer
|
|
|
|
*/
|
|
|
|
static void vmbus_process_offer(struct vmbus_channel *newchannel)
|
|
|
|
{
|
|
|
|
struct vmbus_channel *channel;
|
|
|
|
struct workqueue_struct *wq;
|
|
|
|
bool fnew = true;
|
|
|
|
|
2020-04-05 20:15:12 -04:00
|
|
|
/*
|
2020-05-22 13:19:00 -04:00
|
|
|
* Synchronize vmbus_process_offer() and CPU hotplugging:
|
2020-04-05 20:15:12 -04:00
|
|
|
*
|
|
|
|
* CPU1 CPU2
|
|
|
|
*
|
2020-05-22 13:19:00 -04:00
|
|
|
* [vmbus_process_offer()] [Hot removal of the CPU]
|
2020-04-05 20:15:12 -04:00
|
|
|
*
|
2020-05-22 13:19:00 -04:00
|
|
|
* CPU_READ_LOCK CPUS_WRITE_LOCK
|
|
|
|
* LOAD cpu_online_mask SEARCH chn_list
|
|
|
|
* STORE target_cpu LOAD target_cpu
|
|
|
|
* INSERT chn_list STORE cpu_online_mask
|
|
|
|
* CPUS_READ_UNLOCK CPUS_WRITE_UNLOCK
|
|
|
|
*
|
|
|
|
* Forbids: CPU1's LOAD from *not* seing CPU2's STORE &&
|
2021-03-10 00:21:55 -05:00
|
|
|
* CPU2's SEARCH from *not* seeing CPU1's INSERT
|
2020-04-05 20:15:12 -04:00
|
|
|
*
|
|
|
|
* Forbids: CPU2's SEARCH from seeing CPU1's INSERT &&
|
2021-03-10 00:21:55 -05:00
|
|
|
* CPU2's LOAD from *not* seing CPU1's STORE
|
2020-04-05 20:15:12 -04:00
|
|
|
*/
|
2020-05-22 13:19:00 -04:00
|
|
|
cpus_read_lock();
|
2020-04-05 20:15:12 -04:00
|
|
|
|
2020-05-22 13:19:00 -04:00
|
|
|
/*
|
|
|
|
* Serializes the modifications of the chn_list list as well as
|
|
|
|
* the accesses to next_numa_node_id in init_vp_index().
|
|
|
|
*/
|
Drivers: hv: vmbus: Offload the handling of channels to two workqueues
vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.
The above is also true for primary channels, if the related device
drivers use sync probing mode by default.
And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.
The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).
The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.
So actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.
Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-02 19:54:35 -05:00
|
|
|
mutex_lock(&vmbus_connection.channel_mutex);
|
|
|
|
|
Drivers: hv: vmbus: Fix duplicate CPU assignments within a device
The vmbus module uses a rotational algorithm to assign target CPUs to
a device's channels. Depending on the timing of different device's channel
offers, different channels of a device may be assigned to the same CPU.
For example on a VM with 2 CPUs, if NIC A and B's channels are offered
in the following order, NIC A will have both channels on CPU0, and
NIC B will have both channels on CPU1 -- see below. This kind of
assignment causes RSS load that is spreading across different channels
to end up on the same CPU.
Timing of channel offers:
NIC A channel 0
NIC B channel 0
NIC A channel 1
NIC B channel 1
VMBUS ID 14: Class_ID = {f8615163-df3e-46c5-913f-f2d2f965ed0e} - Synthetic network adapter
Device_ID = {cab064cd-1f31-47d5-a8b4-9d57e320cccd}
Sysfs path: /sys/bus/vmbus/devices/cab064cd-1f31-47d5-a8b4-9d57e320cccd
Rel_ID=14, target_cpu=0
Rel_ID=17, target_cpu=0
VMBUS ID 16: Class_ID = {f8615163-df3e-46c5-913f-f2d2f965ed0e} - Synthetic network adapter
Device_ID = {244225ca-743e-4020-a17d-d7baa13d6cea}
Sysfs path: /sys/bus/vmbus/devices/244225ca-743e-4020-a17d-d7baa13d6cea
Rel_ID=16, target_cpu=1
Rel_ID=18, target_cpu=1
Update the vmbus CPU assignment algorithm to avoid duplicate CPU
assignments within a device.
The new algorithm iterates num_online_cpus + 1 times.
The existing rotational algorithm to find "next NUMA & CPU" is still here.
But if the resulting CPU is already used by the same device, it will try
the next CPU.
In the last iteration, it assigns the channel to the next available CPU
like the existing algorithm. This is not normally expected, because
during device probe, we limit the number of channels of a device to
be <= number of online CPUs.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Tested-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/1626459673-17420-1-git-send-email-haiyangz@microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2021-07-16 14:21:13 -04:00
|
|
|
list_for_each_entry(channel, &vmbus_connection.chn_list, listentry) {
|
|
|
|
if (guid_equal(&channel->offermsg.offer.if_type,
|
|
|
|
&newchannel->offermsg.offer.if_type) &&
|
|
|
|
guid_equal(&channel->offermsg.offer.if_instance,
|
|
|
|
&newchannel->offermsg.offer.if_instance)) {
|
|
|
|
fnew = false;
|
|
|
|
newchannel->primary_channel = channel;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Drivers: hv: vmbus: Resolve more races involving init_vp_index()
init_vp_index() uses the (per-node) hv_numa_map[] masks to record the
CPUs allocated for channel interrupts at a given time, and distribute
the performance-critical channels across the available CPUs: in part.,
the mask of "candidate" target CPUs in a given NUMA node, for a newly
offered channel, is determined by XOR-ing the node's CPU mask and the
node's hv_numa_map. This operation/mechanism assumes that no offline
CPUs is set in the hv_numa_map mask, an assumption that does not hold
since such mask is currently not updated when a channel is removed or
assigned to a different CPU.
To address the issues described above, this adds hooks in the channel
removal path (hv_process_channel_removal()) and in target_cpu_store()
in order to clear, resp. to update, the hv_numa_map[] masks as needed.
This also adds a (missed) update of the masks in init_vp_index() (cf.,
e.g., the memory-allocation failure path in this function).
Like in the case of init_vp_index(), such hooks require to determine
if the given channel is performance critical. init_vp_index() does
this by parsing the channel's offer, it can not rely on the device
data structure (device_obj) to retrieve such information because the
device data structure has not been allocated/linked with the channel
by the time that init_vp_index() executes. A similar situation may
hold in hv_is_alloced_cpu() (defined below); the adopted approach is
to "cache" the device type of the channel, as computed by parsing the
channel's offer, in the channel structure itself.
Fixes: 7527810573436f ("Drivers: hv: vmbus: Introduce the CHANNELMSG_MODIFYCHANNEL message type")
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200522171901.204127-3-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2020-05-22 13:19:01 -04:00
|
|
|
init_vp_index(newchannel);
|
2020-05-22 13:19:00 -04:00
|
|
|
|
2019-09-05 19:01:21 -04:00
|
|
|
/* Remember the channels that should be cleaned up upon suspend. */
|
|
|
|
if (is_hvsock_channel(newchannel) || is_sub_channel(newchannel))
|
|
|
|
atomic_inc(&vmbus_connection.nr_chan_close_on_suspend);
|
|
|
|
|
Drivers: hv: vmbus: Offload the handling of channels to two workqueues
vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.
The above is also true for primary channels, if the related device
drivers use sync probing mode by default.
And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.
The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).
The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.
So actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.
Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-02 19:54:35 -05:00
|
|
|
/*
|
|
|
|
* Now that we have acquired the channel_mutex,
|
|
|
|
* we can release the potentially racing rescind thread.
|
|
|
|
*/
|
|
|
|
atomic_dec(&vmbus_connection.offer_in_progress);
|
|
|
|
|
2020-06-17 12:46:40 -04:00
|
|
|
if (fnew) {
|
Drivers: hv: vmbus: Offload the handling of channels to two workqueues
vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.
The above is also true for primary channels, if the related device
drivers use sync probing mode by default.
And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.
The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).
The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.
So actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.
Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-02 19:54:35 -05:00
|
|
|
list_add_tail(&newchannel->listentry,
|
|
|
|
&vmbus_connection.chn_list);
|
2020-06-17 12:46:40 -04:00
|
|
|
} else {
|
Drivers: hv: vmbus: Offload the handling of channels to two workqueues
vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.
The above is also true for primary channels, if the related device
drivers use sync probing mode by default.
And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.
The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).
The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.
So actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.
Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-02 19:54:35 -05:00
|
|
|
/*
|
|
|
|
* Check to see if this is a valid sub-channel.
|
|
|
|
*/
|
|
|
|
if (newchannel->offermsg.offer.sub_channel_index == 0) {
|
|
|
|
mutex_unlock(&vmbus_connection.channel_mutex);
|
2022-06-09 13:16:36 -04:00
|
|
|
cpus_read_unlock();
|
Drivers: hv: vmbus: Offload the handling of channels to two workqueues
vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.
The above is also true for primary channels, if the related device
drivers use sync probing mode by default.
And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.
The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).
The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.
So actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.
Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-02 19:54:35 -05:00
|
|
|
/*
|
|
|
|
* Don't call free_channel(), because newchannel->kobj
|
|
|
|
* is not initialized yet.
|
|
|
|
*/
|
|
|
|
kfree(newchannel);
|
|
|
|
WARN_ON_ONCE(1);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* Process the sub-channel.
|
|
|
|
*/
|
|
|
|
list_add_tail(&newchannel->sc_list, &channel->sc_list);
|
|
|
|
}
|
|
|
|
|
2020-04-05 20:15:06 -04:00
|
|
|
vmbus_channel_map_relid(newchannel);
|
|
|
|
|
Drivers: hv: vmbus: Offload the handling of channels to two workqueues
vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.
The above is also true for primary channels, if the related device
drivers use sync probing mode by default.
And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.
The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).
The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.
So actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.
Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-02 19:54:35 -05:00
|
|
|
mutex_unlock(&vmbus_connection.channel_mutex);
|
2020-05-22 13:19:00 -04:00
|
|
|
cpus_read_unlock();
|
Drivers: hv: vmbus: Offload the handling of channels to two workqueues
vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.
The above is also true for primary channels, if the related device
drivers use sync probing mode by default.
And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.
The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).
The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.
So actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.
Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-02 19:54:35 -05:00
|
|
|
|
|
|
|
/*
|
|
|
|
* vmbus_process_offer() mustn't call channel->sc_creation_callback()
|
|
|
|
* directly for sub-channels, because sc_creation_callback() ->
|
|
|
|
* vmbus_open() may never get the host's response to the
|
|
|
|
* OPEN_CHANNEL message (the host may rescind a channel at any time,
|
|
|
|
* e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
|
|
|
|
* may not wake up the vmbus_open() as it's blocked due to a non-zero
|
|
|
|
* vmbus_connection.offer_in_progress, and finally we have a deadlock.
|
|
|
|
*
|
|
|
|
* The above is also true for primary channels, if the related device
|
|
|
|
* drivers use sync probing mode by default.
|
|
|
|
*
|
|
|
|
* And, usually the handling of primary channels and sub-channels can
|
|
|
|
* depend on each other, so we should offload them to different
|
|
|
|
* workqueues to avoid possible deadlock, e.g. in sync-probing mode,
|
|
|
|
* NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
|
|
|
|
* rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
|
|
|
|
* and waits for all the sub-channels to appear, but the latter
|
|
|
|
* can't get the rtnl_lock and this blocks the handling of
|
|
|
|
* sub-channels.
|
|
|
|
*/
|
|
|
|
INIT_WORK(&newchannel->add_channel_work, vmbus_add_channel_work);
|
|
|
|
wq = fnew ? vmbus_connection.handle_primary_chan_wq :
|
|
|
|
vmbus_connection.handle_sub_chan_wq;
|
|
|
|
queue_work(wq, &newchannel->add_channel_work);
|
|
|
|
}
|
|
|
|
|
Drivers: hv: vmbus: Fix duplicate CPU assignments within a device
The vmbus module uses a rotational algorithm to assign target CPUs to
a device's channels. Depending on the timing of different device's channel
offers, different channels of a device may be assigned to the same CPU.
For example on a VM with 2 CPUs, if NIC A and B's channels are offered
in the following order, NIC A will have both channels on CPU0, and
NIC B will have both channels on CPU1 -- see below. This kind of
assignment causes RSS load that is spreading across different channels
to end up on the same CPU.
Timing of channel offers:
NIC A channel 0
NIC B channel 0
NIC A channel 1
NIC B channel 1
VMBUS ID 14: Class_ID = {f8615163-df3e-46c5-913f-f2d2f965ed0e} - Synthetic network adapter
Device_ID = {cab064cd-1f31-47d5-a8b4-9d57e320cccd}
Sysfs path: /sys/bus/vmbus/devices/cab064cd-1f31-47d5-a8b4-9d57e320cccd
Rel_ID=14, target_cpu=0
Rel_ID=17, target_cpu=0
VMBUS ID 16: Class_ID = {f8615163-df3e-46c5-913f-f2d2f965ed0e} - Synthetic network adapter
Device_ID = {244225ca-743e-4020-a17d-d7baa13d6cea}
Sysfs path: /sys/bus/vmbus/devices/244225ca-743e-4020-a17d-d7baa13d6cea
Rel_ID=16, target_cpu=1
Rel_ID=18, target_cpu=1
Update the vmbus CPU assignment algorithm to avoid duplicate CPU
assignments within a device.
The new algorithm iterates num_online_cpus + 1 times.
The existing rotational algorithm to find "next NUMA & CPU" is still here.
But if the resulting CPU is already used by the same device, it will try
the next CPU.
In the last iteration, it assigns the channel to the next available CPU
like the existing algorithm. This is not normally expected, because
during device probe, we limit the number of channels of a device to
be <= number of online CPUs.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Tested-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/1626459673-17420-1-git-send-email-haiyangz@microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2021-07-16 14:21:13 -04:00
|
|
|
/*
|
|
|
|
* Check if CPUs used by other channels of the same device.
|
|
|
|
* It should only be called by init_vp_index().
|
|
|
|
*/
|
|
|
|
static bool hv_cpuself_used(u32 cpu, struct vmbus_channel *chn)
|
|
|
|
{
|
|
|
|
struct vmbus_channel *primary = chn->primary_channel;
|
|
|
|
struct vmbus_channel *sc;
|
|
|
|
|
|
|
|
lockdep_assert_held(&vmbus_connection.channel_mutex);
|
|
|
|
|
|
|
|
if (!primary)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (primary->target_cpu == cpu)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
list_for_each_entry(sc, &primary->sc_list, sc_list)
|
|
|
|
if (sc != chn && sc->target_cpu == cpu)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2012-12-01 09:46:50 -05:00
|
|
|
/*
|
|
|
|
* We use this state to statically distribute the channel interrupt load.
|
|
|
|
*/
|
2015-05-31 02:37:48 -04:00
|
|
|
static int next_numa_node_id;
|
2012-12-01 09:46:50 -05:00
|
|
|
|
|
|
|
/*
|
2022-05-02 12:36:28 -04:00
|
|
|
* We can statically distribute the incoming channel interrupt load
|
|
|
|
* by binding a channel to VCPU.
|
2015-05-31 02:37:48 -04:00
|
|
|
*
|
2022-05-02 12:36:28 -04:00
|
|
|
* For non-performance critical channels we assign the VMBUS_CONNECT_CPU.
|
|
|
|
* Performance critical channels will be distributed evenly among all
|
|
|
|
* the available NUMA nodes. Once the node is assigned, we will assign
|
|
|
|
* the CPU based on a simple round robin scheme.
|
2012-12-01 09:46:50 -05:00
|
|
|
*/
|
Drivers: hv: vmbus: Resolve more races involving init_vp_index()
init_vp_index() uses the (per-node) hv_numa_map[] masks to record the
CPUs allocated for channel interrupts at a given time, and distribute
the performance-critical channels across the available CPUs: in part.,
the mask of "candidate" target CPUs in a given NUMA node, for a newly
offered channel, is determined by XOR-ing the node's CPU mask and the
node's hv_numa_map. This operation/mechanism assumes that no offline
CPUs is set in the hv_numa_map mask, an assumption that does not hold
since such mask is currently not updated when a channel is removed or
assigned to a different CPU.
To address the issues described above, this adds hooks in the channel
removal path (hv_process_channel_removal()) and in target_cpu_store()
in order to clear, resp. to update, the hv_numa_map[] masks as needed.
This also adds a (missed) update of the masks in init_vp_index() (cf.,
e.g., the memory-allocation failure path in this function).
Like in the case of init_vp_index(), such hooks require to determine
if the given channel is performance critical. init_vp_index() does
this by parsing the channel's offer, it can not rely on the device
data structure (device_obj) to retrieve such information because the
device data structure has not been allocated/linked with the channel
by the time that init_vp_index() executes. A similar situation may
hold in hv_is_alloced_cpu() (defined below); the adopted approach is
to "cache" the device type of the channel, as computed by parsing the
channel's offer, in the channel structure itself.
Fixes: 7527810573436f ("Drivers: hv: vmbus: Introduce the CHANNELMSG_MODIFYCHANNEL message type")
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200522171901.204127-3-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2020-05-22 13:19:01 -04:00
|
|
|
static void init_vp_index(struct vmbus_channel *channel)
|
2012-12-01 09:46:50 -05:00
|
|
|
{
|
Drivers: hv: vmbus: Resolve more races involving init_vp_index()
init_vp_index() uses the (per-node) hv_numa_map[] masks to record the
CPUs allocated for channel interrupts at a given time, and distribute
the performance-critical channels across the available CPUs: in part.,
the mask of "candidate" target CPUs in a given NUMA node, for a newly
offered channel, is determined by XOR-ing the node's CPU mask and the
node's hv_numa_map. This operation/mechanism assumes that no offline
CPUs is set in the hv_numa_map mask, an assumption that does not hold
since such mask is currently not updated when a channel is removed or
assigned to a different CPU.
To address the issues described above, this adds hooks in the channel
removal path (hv_process_channel_removal()) and in target_cpu_store()
in order to clear, resp. to update, the hv_numa_map[] masks as needed.
This also adds a (missed) update of the masks in init_vp_index() (cf.,
e.g., the memory-allocation failure path in this function).
Like in the case of init_vp_index(), such hooks require to determine
if the given channel is performance critical. init_vp_index() does
this by parsing the channel's offer, it can not rely on the device
data structure (device_obj) to retrieve such information because the
device data structure has not been allocated/linked with the channel
by the time that init_vp_index() executes. A similar situation may
hold in hv_is_alloced_cpu() (defined below); the adopted approach is
to "cache" the device type of the channel, as computed by parsing the
channel's offer, in the channel structure itself.
Fixes: 7527810573436f ("Drivers: hv: vmbus: Introduce the CHANNELMSG_MODIFYCHANNEL message type")
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200522171901.204127-3-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2020-05-22 13:19:01 -04:00
|
|
|
bool perf_chn = hv_is_perf_channel(channel);
|
Drivers: hv: vmbus: Fix duplicate CPU assignments within a device
The vmbus module uses a rotational algorithm to assign target CPUs to
a device's channels. Depending on the timing of different device's channel
offers, different channels of a device may be assigned to the same CPU.
For example on a VM with 2 CPUs, if NIC A and B's channels are offered
in the following order, NIC A will have both channels on CPU0, and
NIC B will have both channels on CPU1 -- see below. This kind of
assignment causes RSS load that is spreading across different channels
to end up on the same CPU.
Timing of channel offers:
NIC A channel 0
NIC B channel 0
NIC A channel 1
NIC B channel 1
VMBUS ID 14: Class_ID = {f8615163-df3e-46c5-913f-f2d2f965ed0e} - Synthetic network adapter
Device_ID = {cab064cd-1f31-47d5-a8b4-9d57e320cccd}
Sysfs path: /sys/bus/vmbus/devices/cab064cd-1f31-47d5-a8b4-9d57e320cccd
Rel_ID=14, target_cpu=0
Rel_ID=17, target_cpu=0
VMBUS ID 16: Class_ID = {f8615163-df3e-46c5-913f-f2d2f965ed0e} - Synthetic network adapter
Device_ID = {244225ca-743e-4020-a17d-d7baa13d6cea}
Sysfs path: /sys/bus/vmbus/devices/244225ca-743e-4020-a17d-d7baa13d6cea
Rel_ID=16, target_cpu=1
Rel_ID=18, target_cpu=1
Update the vmbus CPU assignment algorithm to avoid duplicate CPU
assignments within a device.
The new algorithm iterates num_online_cpus + 1 times.
The existing rotational algorithm to find "next NUMA & CPU" is still here.
But if the resulting CPU is already used by the same device, it will try
the next CPU.
In the last iteration, it assigns the channel to the next available CPU
like the existing algorithm. This is not normally expected, because
during device probe, we limit the number of channels of a device to
be <= number of online CPUs.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Tested-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/1626459673-17420-1-git-send-email-haiyangz@microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2021-07-16 14:21:13 -04:00
|
|
|
u32 i, ncpu = num_online_cpus();
|
2018-09-23 17:10:44 -04:00
|
|
|
cpumask_var_t available_mask;
|
2022-01-28 05:34:11 -05:00
|
|
|
struct cpumask *allocated_mask;
|
2022-05-27 03:43:59 -04:00
|
|
|
const struct cpumask *hk_mask = housekeeping_cpumask(HK_TYPE_MANAGED_IRQ);
|
2020-04-05 20:15:11 -04:00
|
|
|
u32 target_cpu;
|
|
|
|
int numa_node;
|
2012-12-01 09:46:50 -05:00
|
|
|
|
2022-05-02 12:36:28 -04:00
|
|
|
if (!perf_chn ||
|
2022-05-27 03:43:59 -04:00
|
|
|
!alloc_cpumask_var(&available_mask, GFP_KERNEL) ||
|
|
|
|
cpumask_empty(hk_mask)) {
|
2012-12-01 09:46:50 -05:00
|
|
|
/*
|
2022-05-02 12:36:28 -04:00
|
|
|
* If the channel is not a performance critical
|
2020-04-05 20:15:12 -04:00
|
|
|
* channel, bind it to VMBUS_CONNECT_CPU.
|
|
|
|
* In case alloc_cpumask_var() fails, bind it to
|
|
|
|
* VMBUS_CONNECT_CPU.
|
2022-05-27 03:43:59 -04:00
|
|
|
* If all the cpus are isolated, bind it to
|
|
|
|
* VMBUS_CONNECT_CPU.
|
2012-12-01 09:46:50 -05:00
|
|
|
*/
|
2020-04-05 20:15:12 -04:00
|
|
|
channel->target_cpu = VMBUS_CONNECT_CPU;
|
Drivers: hv: vmbus: Resolve more races involving init_vp_index()
init_vp_index() uses the (per-node) hv_numa_map[] masks to record the
CPUs allocated for channel interrupts at a given time, and distribute
the performance-critical channels across the available CPUs: in part.,
the mask of "candidate" target CPUs in a given NUMA node, for a newly
offered channel, is determined by XOR-ing the node's CPU mask and the
node's hv_numa_map. This operation/mechanism assumes that no offline
CPUs is set in the hv_numa_map mask, an assumption that does not hold
since such mask is currently not updated when a channel is removed or
assigned to a different CPU.
To address the issues described above, this adds hooks in the channel
removal path (hv_process_channel_removal()) and in target_cpu_store()
in order to clear, resp. to update, the hv_numa_map[] masks as needed.
This also adds a (missed) update of the masks in init_vp_index() (cf.,
e.g., the memory-allocation failure path in this function).
Like in the case of init_vp_index(), such hooks require to determine
if the given channel is performance critical. init_vp_index() does
this by parsing the channel's offer, it can not rely on the device
data structure (device_obj) to retrieve such information because the
device data structure has not been allocated/linked with the channel
by the time that init_vp_index() executes. A similar situation may
hold in hv_is_alloced_cpu() (defined below); the adopted approach is
to "cache" the device type of the channel, as computed by parsing the
channel's offer, in the channel structure itself.
Fixes: 7527810573436f ("Drivers: hv: vmbus: Introduce the CHANNELMSG_MODIFYCHANNEL message type")
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200522171901.204127-3-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2020-05-22 13:19:01 -04:00
|
|
|
if (perf_chn)
|
2022-01-28 05:34:11 -05:00
|
|
|
hv_set_allocated_cpu(VMBUS_CONNECT_CPU);
|
2014-04-08 21:45:53 -04:00
|
|
|
return;
|
2012-12-01 09:46:50 -05:00
|
|
|
}
|
2015-05-06 20:47:46 -04:00
|
|
|
|
Drivers: hv: vmbus: Fix duplicate CPU assignments within a device
The vmbus module uses a rotational algorithm to assign target CPUs to
a device's channels. Depending on the timing of different device's channel
offers, different channels of a device may be assigned to the same CPU.
For example on a VM with 2 CPUs, if NIC A and B's channels are offered
in the following order, NIC A will have both channels on CPU0, and
NIC B will have both channels on CPU1 -- see below. This kind of
assignment causes RSS load that is spreading across different channels
to end up on the same CPU.
Timing of channel offers:
NIC A channel 0
NIC B channel 0
NIC A channel 1
NIC B channel 1
VMBUS ID 14: Class_ID = {f8615163-df3e-46c5-913f-f2d2f965ed0e} - Synthetic network adapter
Device_ID = {cab064cd-1f31-47d5-a8b4-9d57e320cccd}
Sysfs path: /sys/bus/vmbus/devices/cab064cd-1f31-47d5-a8b4-9d57e320cccd
Rel_ID=14, target_cpu=0
Rel_ID=17, target_cpu=0
VMBUS ID 16: Class_ID = {f8615163-df3e-46c5-913f-f2d2f965ed0e} - Synthetic network adapter
Device_ID = {244225ca-743e-4020-a17d-d7baa13d6cea}
Sysfs path: /sys/bus/vmbus/devices/244225ca-743e-4020-a17d-d7baa13d6cea
Rel_ID=16, target_cpu=1
Rel_ID=18, target_cpu=1
Update the vmbus CPU assignment algorithm to avoid duplicate CPU
assignments within a device.
The new algorithm iterates num_online_cpus + 1 times.
The existing rotational algorithm to find "next NUMA & CPU" is still here.
But if the resulting CPU is already used by the same device, it will try
the next CPU.
In the last iteration, it assigns the channel to the next available CPU
like the existing algorithm. This is not normally expected, because
during device probe, we limit the number of channels of a device to
be <= number of online CPUs.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Tested-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/1626459673-17420-1-git-send-email-haiyangz@microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2021-07-16 14:21:13 -04:00
|
|
|
for (i = 1; i <= ncpu + 1; i++) {
|
|
|
|
while (true) {
|
|
|
|
numa_node = next_numa_node_id++;
|
|
|
|
if (numa_node == nr_node_ids) {
|
|
|
|
next_numa_node_id = 0;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (cpumask_empty(cpumask_of_node(numa_node)))
|
|
|
|
continue;
|
|
|
|
break;
|
2015-05-31 02:37:48 -04:00
|
|
|
}
|
2022-01-28 05:34:11 -05:00
|
|
|
allocated_mask = &hv_context.hv_numa_map[numa_node];
|
2015-05-31 02:37:48 -04:00
|
|
|
|
2022-05-27 03:43:59 -04:00
|
|
|
retry:
|
|
|
|
cpumask_xor(available_mask, allocated_mask, cpumask_of_node(numa_node));
|
|
|
|
cpumask_and(available_mask, available_mask, hk_mask);
|
|
|
|
|
|
|
|
if (cpumask_empty(available_mask)) {
|
Drivers: hv: vmbus: Fix duplicate CPU assignments within a device
The vmbus module uses a rotational algorithm to assign target CPUs to
a device's channels. Depending on the timing of different device's channel
offers, different channels of a device may be assigned to the same CPU.
For example on a VM with 2 CPUs, if NIC A and B's channels are offered
in the following order, NIC A will have both channels on CPU0, and
NIC B will have both channels on CPU1 -- see below. This kind of
assignment causes RSS load that is spreading across different channels
to end up on the same CPU.
Timing of channel offers:
NIC A channel 0
NIC B channel 0
NIC A channel 1
NIC B channel 1
VMBUS ID 14: Class_ID = {f8615163-df3e-46c5-913f-f2d2f965ed0e} - Synthetic network adapter
Device_ID = {cab064cd-1f31-47d5-a8b4-9d57e320cccd}
Sysfs path: /sys/bus/vmbus/devices/cab064cd-1f31-47d5-a8b4-9d57e320cccd
Rel_ID=14, target_cpu=0
Rel_ID=17, target_cpu=0
VMBUS ID 16: Class_ID = {f8615163-df3e-46c5-913f-f2d2f965ed0e} - Synthetic network adapter
Device_ID = {244225ca-743e-4020-a17d-d7baa13d6cea}
Sysfs path: /sys/bus/vmbus/devices/244225ca-743e-4020-a17d-d7baa13d6cea
Rel_ID=16, target_cpu=1
Rel_ID=18, target_cpu=1
Update the vmbus CPU assignment algorithm to avoid duplicate CPU
assignments within a device.
The new algorithm iterates num_online_cpus + 1 times.
The existing rotational algorithm to find "next NUMA & CPU" is still here.
But if the resulting CPU is already used by the same device, it will try
the next CPU.
In the last iteration, it assigns the channel to the next available CPU
like the existing algorithm. This is not normally expected, because
during device probe, we limit the number of channels of a device to
be <= number of online CPUs.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Tested-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/1626459673-17420-1-git-send-email-haiyangz@microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2021-07-16 14:21:13 -04:00
|
|
|
/*
|
|
|
|
* We have cycled through all the CPUs in the node;
|
2022-01-28 05:34:11 -05:00
|
|
|
* reset the allocated map.
|
Drivers: hv: vmbus: Fix duplicate CPU assignments within a device
The vmbus module uses a rotational algorithm to assign target CPUs to
a device's channels. Depending on the timing of different device's channel
offers, different channels of a device may be assigned to the same CPU.
For example on a VM with 2 CPUs, if NIC A and B's channels are offered
in the following order, NIC A will have both channels on CPU0, and
NIC B will have both channels on CPU1 -- see below. This kind of
assignment causes RSS load that is spreading across different channels
to end up on the same CPU.
Timing of channel offers:
NIC A channel 0
NIC B channel 0
NIC A channel 1
NIC B channel 1
VMBUS ID 14: Class_ID = {f8615163-df3e-46c5-913f-f2d2f965ed0e} - Synthetic network adapter
Device_ID = {cab064cd-1f31-47d5-a8b4-9d57e320cccd}
Sysfs path: /sys/bus/vmbus/devices/cab064cd-1f31-47d5-a8b4-9d57e320cccd
Rel_ID=14, target_cpu=0
Rel_ID=17, target_cpu=0
VMBUS ID 16: Class_ID = {f8615163-df3e-46c5-913f-f2d2f965ed0e} - Synthetic network adapter
Device_ID = {244225ca-743e-4020-a17d-d7baa13d6cea}
Sysfs path: /sys/bus/vmbus/devices/244225ca-743e-4020-a17d-d7baa13d6cea
Rel_ID=16, target_cpu=1
Rel_ID=18, target_cpu=1
Update the vmbus CPU assignment algorithm to avoid duplicate CPU
assignments within a device.
The new algorithm iterates num_online_cpus + 1 times.
The existing rotational algorithm to find "next NUMA & CPU" is still here.
But if the resulting CPU is already used by the same device, it will try
the next CPU.
In the last iteration, it assigns the channel to the next available CPU
like the existing algorithm. This is not normally expected, because
during device probe, we limit the number of channels of a device to
be <= number of online CPUs.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Tested-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/1626459673-17420-1-git-send-email-haiyangz@microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2021-07-16 14:21:13 -04:00
|
|
|
*/
|
2022-01-28 05:34:11 -05:00
|
|
|
cpumask_clear(allocated_mask);
|
2022-05-27 03:43:59 -04:00
|
|
|
goto retry;
|
Drivers: hv: vmbus: Fix duplicate CPU assignments within a device
The vmbus module uses a rotational algorithm to assign target CPUs to
a device's channels. Depending on the timing of different device's channel
offers, different channels of a device may be assigned to the same CPU.
For example on a VM with 2 CPUs, if NIC A and B's channels are offered
in the following order, NIC A will have both channels on CPU0, and
NIC B will have both channels on CPU1 -- see below. This kind of
assignment causes RSS load that is spreading across different channels
to end up on the same CPU.
Timing of channel offers:
NIC A channel 0
NIC B channel 0
NIC A channel 1
NIC B channel 1
VMBUS ID 14: Class_ID = {f8615163-df3e-46c5-913f-f2d2f965ed0e} - Synthetic network adapter
Device_ID = {cab064cd-1f31-47d5-a8b4-9d57e320cccd}
Sysfs path: /sys/bus/vmbus/devices/cab064cd-1f31-47d5-a8b4-9d57e320cccd
Rel_ID=14, target_cpu=0
Rel_ID=17, target_cpu=0
VMBUS ID 16: Class_ID = {f8615163-df3e-46c5-913f-f2d2f965ed0e} - Synthetic network adapter
Device_ID = {244225ca-743e-4020-a17d-d7baa13d6cea}
Sysfs path: /sys/bus/vmbus/devices/244225ca-743e-4020-a17d-d7baa13d6cea
Rel_ID=16, target_cpu=1
Rel_ID=18, target_cpu=1
Update the vmbus CPU assignment algorithm to avoid duplicate CPU
assignments within a device.
The new algorithm iterates num_online_cpus + 1 times.
The existing rotational algorithm to find "next NUMA & CPU" is still here.
But if the resulting CPU is already used by the same device, it will try
the next CPU.
In the last iteration, it assigns the channel to the next available CPU
like the existing algorithm. This is not normally expected, because
during device probe, we limit the number of channels of a device to
be <= number of online CPUs.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Tested-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/1626459673-17420-1-git-send-email-haiyangz@microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2021-07-16 14:21:13 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
target_cpu = cpumask_first(available_mask);
|
2022-01-28 05:34:11 -05:00
|
|
|
cpumask_set_cpu(target_cpu, allocated_mask);
|
2015-08-05 03:52:39 -04:00
|
|
|
|
Drivers: hv: vmbus: Fix duplicate CPU assignments within a device
The vmbus module uses a rotational algorithm to assign target CPUs to
a device's channels. Depending on the timing of different device's channel
offers, different channels of a device may be assigned to the same CPU.
For example on a VM with 2 CPUs, if NIC A and B's channels are offered
in the following order, NIC A will have both channels on CPU0, and
NIC B will have both channels on CPU1 -- see below. This kind of
assignment causes RSS load that is spreading across different channels
to end up on the same CPU.
Timing of channel offers:
NIC A channel 0
NIC B channel 0
NIC A channel 1
NIC B channel 1
VMBUS ID 14: Class_ID = {f8615163-df3e-46c5-913f-f2d2f965ed0e} - Synthetic network adapter
Device_ID = {cab064cd-1f31-47d5-a8b4-9d57e320cccd}
Sysfs path: /sys/bus/vmbus/devices/cab064cd-1f31-47d5-a8b4-9d57e320cccd
Rel_ID=14, target_cpu=0
Rel_ID=17, target_cpu=0
VMBUS ID 16: Class_ID = {f8615163-df3e-46c5-913f-f2d2f965ed0e} - Synthetic network adapter
Device_ID = {244225ca-743e-4020-a17d-d7baa13d6cea}
Sysfs path: /sys/bus/vmbus/devices/244225ca-743e-4020-a17d-d7baa13d6cea
Rel_ID=16, target_cpu=1
Rel_ID=18, target_cpu=1
Update the vmbus CPU assignment algorithm to avoid duplicate CPU
assignments within a device.
The new algorithm iterates num_online_cpus + 1 times.
The existing rotational algorithm to find "next NUMA & CPU" is still here.
But if the resulting CPU is already used by the same device, it will try
the next CPU.
In the last iteration, it assigns the channel to the next available CPU
like the existing algorithm. This is not normally expected, because
during device probe, we limit the number of channels of a device to
be <= number of online CPUs.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Tested-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/1626459673-17420-1-git-send-email-haiyangz@microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2021-07-16 14:21:13 -04:00
|
|
|
if (channel->offermsg.offer.sub_channel_index >= ncpu ||
|
|
|
|
i > ncpu || !hv_cpuself_used(target_cpu, channel))
|
|
|
|
break;
|
|
|
|
}
|
2015-05-31 02:37:48 -04:00
|
|
|
|
2020-04-05 20:15:11 -04:00
|
|
|
channel->target_cpu = target_cpu;
|
2018-09-23 17:10:44 -04:00
|
|
|
|
|
|
|
free_cpumask_var(available_mask);
|
2012-12-01 09:46:50 -05:00
|
|
|
}
|
|
|
|
|
2021-04-20 00:48:09 -04:00
|
|
|
#define UNLOAD_DELAY_UNIT_MS 10 /* 10 milliseconds */
|
|
|
|
#define UNLOAD_WAIT_MS (100*1000) /* 100 seconds */
|
|
|
|
#define UNLOAD_WAIT_LOOPS (UNLOAD_WAIT_MS/UNLOAD_DELAY_UNIT_MS)
|
|
|
|
#define UNLOAD_MSG_MS (5*1000) /* Every 5 seconds */
|
|
|
|
#define UNLOAD_MSG_LOOPS (UNLOAD_MSG_MS/UNLOAD_DELAY_UNIT_MS)
|
|
|
|
|
2016-01-28 01:29:35 -05:00
|
|
|
static void vmbus_wait_for_unload(void)
|
|
|
|
{
|
2016-04-30 22:21:34 -04:00
|
|
|
int cpu;
|
|
|
|
void *page_addr;
|
|
|
|
struct hv_message *msg;
|
2016-01-28 01:29:35 -05:00
|
|
|
struct vmbus_channel_message_header *hdr;
|
2020-09-13 15:47:29 -04:00
|
|
|
u32 message_type, i;
|
2016-01-28 01:29:35 -05:00
|
|
|
|
2016-04-30 22:21:34 -04:00
|
|
|
/*
|
|
|
|
* CHANNELMSG_UNLOAD_RESPONSE is always delivered to the CPU which was
|
|
|
|
* used for initial contact or to CPU0 depending on host version. When
|
|
|
|
* we're crashing on a different CPU let's hope that IRQ handler on
|
|
|
|
* the cpu which receives CHANNELMSG_UNLOAD_RESPONSE is still
|
|
|
|
* functional and vmbus_unload_response() will complete
|
|
|
|
* vmbus_connection.unload_event. If not, the last thing we can do is
|
|
|
|
* read message pages for all CPUs directly.
|
2020-09-13 15:47:29 -04:00
|
|
|
*
|
2021-04-20 00:48:09 -04:00
|
|
|
* Wait up to 100 seconds since an Azure host must writeback any dirty
|
|
|
|
* data in its disk cache before the VMbus UNLOAD request will
|
|
|
|
* complete. This flushing has been empirically observed to take up
|
|
|
|
* to 50 seconds in cases with a lot of dirty data, so allow additional
|
|
|
|
* leeway and for inaccuracies in mdelay(). But eventually time out so
|
|
|
|
* that the panic path can't get hung forever in case the response
|
|
|
|
* message isn't seen.
|
2016-04-30 22:21:34 -04:00
|
|
|
*/
|
2021-04-20 00:48:09 -04:00
|
|
|
for (i = 1; i <= UNLOAD_WAIT_LOOPS; i++) {
|
2016-04-30 22:21:34 -04:00
|
|
|
if (completion_done(&vmbus_connection.unload_event))
|
2021-04-20 00:48:09 -04:00
|
|
|
goto completed;
|
2016-01-28 01:29:35 -05:00
|
|
|
|
2023-05-18 11:13:52 -04:00
|
|
|
for_each_present_cpu(cpu) {
|
2017-02-12 01:02:19 -05:00
|
|
|
struct hv_per_cpu_context *hv_cpu
|
|
|
|
= per_cpu_ptr(hv_context.cpu_context, cpu);
|
|
|
|
|
2023-05-18 11:13:52 -04:00
|
|
|
/*
|
|
|
|
* In a CoCo VM the synic_message_page is not allocated
|
|
|
|
* in hv_synic_alloc(). Instead it is set/cleared in
|
|
|
|
* hv_synic_enable_regs() and hv_synic_disable_regs()
|
|
|
|
* such that it is set only when the CPU is online. If
|
|
|
|
* not all present CPUs are online, the message page
|
|
|
|
* might be NULL, so skip such CPUs.
|
|
|
|
*/
|
2017-02-12 01:02:19 -05:00
|
|
|
page_addr = hv_cpu->synic_message_page;
|
2023-05-18 11:13:52 -04:00
|
|
|
if (!page_addr)
|
|
|
|
continue;
|
|
|
|
|
2017-02-12 01:02:19 -05:00
|
|
|
msg = (struct hv_message *)page_addr
|
|
|
|
+ VMBUS_MESSAGE_SINT;
|
2016-01-28 01:29:35 -05:00
|
|
|
|
2016-04-30 22:21:34 -04:00
|
|
|
message_type = READ_ONCE(msg->header.message_type);
|
|
|
|
if (message_type == HVMSG_NONE)
|
|
|
|
continue;
|
2016-01-28 01:29:35 -05:00
|
|
|
|
2016-04-30 22:21:34 -04:00
|
|
|
hdr = (struct vmbus_channel_message_header *)
|
|
|
|
msg->u.payload;
|
|
|
|
|
|
|
|
if (hdr->msgtype == CHANNELMSG_UNLOAD_RESPONSE)
|
|
|
|
complete(&vmbus_connection.unload_event);
|
|
|
|
|
|
|
|
vmbus_signal_eom(msg, message_type);
|
|
|
|
}
|
|
|
|
|
2021-04-20 00:48:09 -04:00
|
|
|
/*
|
|
|
|
* Give a notice periodically so someone watching the
|
|
|
|
* serial output won't think it is completely hung.
|
|
|
|
*/
|
|
|
|
if (!(i % UNLOAD_MSG_LOOPS))
|
|
|
|
pr_notice("Waiting for VMBus UNLOAD to complete\n");
|
|
|
|
|
|
|
|
mdelay(UNLOAD_DELAY_UNIT_MS);
|
2016-04-30 22:21:34 -04:00
|
|
|
}
|
2021-04-20 00:48:09 -04:00
|
|
|
pr_err("Continuing even though VMBus UNLOAD did not complete\n");
|
2016-04-30 22:21:34 -04:00
|
|
|
|
2021-04-20 00:48:09 -04:00
|
|
|
completed:
|
2016-04-30 22:21:34 -04:00
|
|
|
/*
|
|
|
|
* We're crashing and already got the UNLOAD_RESPONSE, cleanup all
|
|
|
|
* maybe-pending messages on all CPUs to be able to receive new
|
|
|
|
* messages after we reconnect.
|
|
|
|
*/
|
2023-05-18 11:13:52 -04:00
|
|
|
for_each_present_cpu(cpu) {
|
2017-02-12 01:02:19 -05:00
|
|
|
struct hv_per_cpu_context *hv_cpu
|
|
|
|
= per_cpu_ptr(hv_context.cpu_context, cpu);
|
|
|
|
|
|
|
|
page_addr = hv_cpu->synic_message_page;
|
2023-05-18 11:13:52 -04:00
|
|
|
if (!page_addr)
|
|
|
|
continue;
|
|
|
|
|
2016-04-30 22:21:34 -04:00
|
|
|
msg = (struct hv_message *)page_addr + VMBUS_MESSAGE_SINT;
|
|
|
|
msg->header.message_type = HVMSG_NONE;
|
2016-01-28 01:29:35 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-04-23 00:31:32 -04:00
|
|
|
/*
|
|
|
|
* vmbus_unload_response - Handler for the unload response.
|
|
|
|
*/
|
|
|
|
static void vmbus_unload_response(struct vmbus_channel_message_header *hdr)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* This is a global event; just wakeup the waiting thread.
|
|
|
|
* Once we successfully unload, we can cleanup the monitor state.
|
2021-04-19 21:43:50 -04:00
|
|
|
*
|
|
|
|
* NB. A malicious or compromised Hyper-V could send a spurious
|
|
|
|
* message of type CHANNELMSG_UNLOAD_RESPONSE, and trigger a call
|
|
|
|
* of the complete() below. Make sure that unload_event has been
|
|
|
|
* initialized by the time this complete() is executed.
|
2015-04-23 00:31:32 -04:00
|
|
|
*/
|
|
|
|
complete(&vmbus_connection.unload_event);
|
|
|
|
}
|
|
|
|
|
2016-02-26 18:13:16 -05:00
|
|
|
void vmbus_initiate_unload(bool crash)
|
2015-04-23 00:31:32 -04:00
|
|
|
{
|
|
|
|
struct vmbus_channel_message_header hdr;
|
|
|
|
|
2020-04-06 11:53:26 -04:00
|
|
|
if (xchg(&vmbus_connection.conn_state, DISCONNECTED) == DISCONNECTED)
|
|
|
|
return;
|
|
|
|
|
2015-08-01 19:08:19 -04:00
|
|
|
/* Pre-Win2012R2 hosts don't support reconnect */
|
|
|
|
if (vmbus_proto_version < VERSION_WIN8_1)
|
|
|
|
return;
|
|
|
|
|
2021-04-19 21:43:50 -04:00
|
|
|
reinit_completion(&vmbus_connection.unload_event);
|
2015-04-23 00:31:32 -04:00
|
|
|
memset(&hdr, 0, sizeof(struct vmbus_channel_message_header));
|
|
|
|
hdr.msgtype = CHANNELMSG_UNLOAD;
|
2016-12-07 04:16:24 -05:00
|
|
|
vmbus_post_msg(&hdr, sizeof(struct vmbus_channel_message_header),
|
|
|
|
!crash);
|
2015-04-23 00:31:32 -04:00
|
|
|
|
2016-01-28 01:29:35 -05:00
|
|
|
/*
|
|
|
|
* vmbus_initiate_unload() is also called on crash and the crash can be
|
|
|
|
* happening in an interrupt context, where scheduling is impossible.
|
|
|
|
*/
|
2016-02-26 18:13:16 -05:00
|
|
|
if (!crash)
|
2016-01-28 01:29:35 -05:00
|
|
|
wait_for_completion(&vmbus_connection.unload_event);
|
|
|
|
else
|
|
|
|
vmbus_wait_for_unload();
|
2015-04-23 00:31:32 -04:00
|
|
|
}
|
|
|
|
|
2019-09-05 19:01:22 -04:00
|
|
|
static void check_ready_for_resume_event(void)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If all the old primary channels have been fixed up, then it's safe
|
|
|
|
* to resume.
|
|
|
|
*/
|
|
|
|
if (atomic_dec_and_test(&vmbus_connection.nr_chan_fixup_on_resume))
|
|
|
|
complete(&vmbus_connection.ready_for_resume_event);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void vmbus_setup_channel_state(struct vmbus_channel *channel,
|
|
|
|
struct vmbus_channel_offer_channel *offer)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Setup state for signalling the host.
|
|
|
|
*/
|
|
|
|
channel->sig_event = VMBUS_EVENT_CONNECTION_ID;
|
|
|
|
|
2022-05-02 12:36:28 -04:00
|
|
|
channel->is_dedicated_interrupt =
|
|
|
|
(offer->is_dedicated_interrupt != 0);
|
|
|
|
channel->sig_event = offer->connection_id;
|
2019-09-05 19:01:22 -04:00
|
|
|
|
|
|
|
memcpy(&channel->offermsg, offer,
|
|
|
|
sizeof(struct vmbus_channel_offer_channel));
|
|
|
|
channel->monitor_grp = (u8)offer->monitorid / 32;
|
|
|
|
channel->monitor_bit = (u8)offer->monitorid % 32;
|
Drivers: hv: vmbus: Resolve more races involving init_vp_index()
init_vp_index() uses the (per-node) hv_numa_map[] masks to record the
CPUs allocated for channel interrupts at a given time, and distribute
the performance-critical channels across the available CPUs: in part.,
the mask of "candidate" target CPUs in a given NUMA node, for a newly
offered channel, is determined by XOR-ing the node's CPU mask and the
node's hv_numa_map. This operation/mechanism assumes that no offline
CPUs is set in the hv_numa_map mask, an assumption that does not hold
since such mask is currently not updated when a channel is removed or
assigned to a different CPU.
To address the issues described above, this adds hooks in the channel
removal path (hv_process_channel_removal()) and in target_cpu_store()
in order to clear, resp. to update, the hv_numa_map[] masks as needed.
This also adds a (missed) update of the masks in init_vp_index() (cf.,
e.g., the memory-allocation failure path in this function).
Like in the case of init_vp_index(), such hooks require to determine
if the given channel is performance critical. init_vp_index() does
this by parsing the channel's offer, it can not rely on the device
data structure (device_obj) to retrieve such information because the
device data structure has not been allocated/linked with the channel
by the time that init_vp_index() executes. A similar situation may
hold in hv_is_alloced_cpu() (defined below); the adopted approach is
to "cache" the device type of the channel, as computed by parsing the
channel's offer, in the channel structure itself.
Fixes: 7527810573436f ("Drivers: hv: vmbus: Introduce the CHANNELMSG_MODIFYCHANNEL message type")
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200522171901.204127-3-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2020-05-22 13:19:01 -04:00
|
|
|
channel->device_id = hv_get_dev_type(channel);
|
2019-09-05 19:01:22 -04:00
|
|
|
}
|
|
|
|
|
2019-09-05 19:01:18 -04:00
|
|
|
/*
|
|
|
|
* find_primary_channel_by_offer - Get the channel object given the new offer.
|
|
|
|
* This is only used in the resume path of hibernation.
|
|
|
|
*/
|
|
|
|
static struct vmbus_channel *
|
|
|
|
find_primary_channel_by_offer(const struct vmbus_channel_offer_channel *offer)
|
|
|
|
{
|
|
|
|
struct vmbus_channel *channel = NULL, *iter;
|
|
|
|
const guid_t *inst1, *inst2;
|
|
|
|
|
|
|
|
/* Ignore sub-channel offers. */
|
|
|
|
if (offer->offer.sub_channel_index != 0)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
mutex_lock(&vmbus_connection.channel_mutex);
|
|
|
|
|
|
|
|
list_for_each_entry(iter, &vmbus_connection.chn_list, listentry) {
|
|
|
|
inst1 = &iter->offermsg.offer.if_instance;
|
|
|
|
inst2 = &offer->offer.if_instance;
|
|
|
|
|
|
|
|
if (guid_equal(inst1, inst2)) {
|
|
|
|
channel = iter;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&vmbus_connection.channel_mutex);
|
|
|
|
|
|
|
|
return channel;
|
|
|
|
}
|
|
|
|
|
2022-04-28 10:51:06 -04:00
|
|
|
static bool vmbus_is_valid_offer(const struct vmbus_channel_offer_channel *offer)
|
2021-02-01 09:48:12 -05:00
|
|
|
{
|
2022-04-28 10:51:06 -04:00
|
|
|
const guid_t *guid = &offer->offer.if_type;
|
2021-02-01 09:48:12 -05:00
|
|
|
u16 i;
|
|
|
|
|
|
|
|
if (!hv_is_isolation_supported())
|
|
|
|
return true;
|
|
|
|
|
2022-04-28 10:51:06 -04:00
|
|
|
if (is_hvsock_offer(offer))
|
|
|
|
return true;
|
|
|
|
|
2021-02-01 09:48:12 -05:00
|
|
|
for (i = 0; i < ARRAY_SIZE(vmbus_devs); i++) {
|
|
|
|
if (guid_equal(guid, &vmbus_devs[i].guid))
|
|
|
|
return vmbus_devs[i].allowed_in_isolated;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2010-03-04 17:11:00 -05:00
|
|
|
/*
|
2010-10-15 13:14:07 -04:00
|
|
|
* vmbus_onoffer - Handler for channel offers from vmbus in parent partition.
|
2009-09-01 00:47:21 -04:00
|
|
|
*
|
|
|
|
*/
|
2010-10-15 13:14:07 -04:00
|
|
|
static void vmbus_onoffer(struct vmbus_channel_message_header *hdr)
|
2009-07-13 19:02:34 -04:00
|
|
|
{
|
2009-09-01 00:47:21 -04:00
|
|
|
struct vmbus_channel_offer_channel *offer;
|
2019-09-05 19:01:18 -04:00
|
|
|
struct vmbus_channel *oldchannel, *newchannel;
|
|
|
|
size_t offer_sz;
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2009-09-01 00:47:21 -04:00
|
|
|
offer = (struct vmbus_channel_offer_channel *)hdr;
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2017-10-29 15:21:02 -04:00
|
|
|
trace_vmbus_onoffer(offer);
|
|
|
|
|
2022-04-28 10:51:06 -04:00
|
|
|
if (!vmbus_is_valid_offer(offer)) {
|
2021-02-01 09:48:12 -05:00
|
|
|
pr_err_ratelimited("Invalid offer %d from the host supporting isolation\n",
|
|
|
|
offer->child_relid);
|
|
|
|
atomic_dec(&vmbus_connection.offer_in_progress);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-09-05 19:01:18 -04:00
|
|
|
oldchannel = find_primary_channel_by_offer(offer);
|
|
|
|
|
|
|
|
if (oldchannel != NULL) {
|
|
|
|
/*
|
2019-09-05 19:01:22 -04:00
|
|
|
* We're resuming from hibernation: all the sub-channel and
|
|
|
|
* hv_sock channels we had before the hibernation should have
|
|
|
|
* been cleaned up, and now we must be seeing a re-offered
|
|
|
|
* primary channel that we had before the hibernation.
|
2019-09-05 19:01:18 -04:00
|
|
|
*/
|
2019-09-05 19:01:22 -04:00
|
|
|
|
2020-04-05 20:15:06 -04:00
|
|
|
/*
|
|
|
|
* { Initially: channel relid = INVALID_RELID,
|
|
|
|
* channels[valid_relid] = NULL }
|
|
|
|
*
|
|
|
|
* CPU1 CPU2
|
|
|
|
*
|
|
|
|
* [vmbus_onoffer()] [vmbus_device_release()]
|
|
|
|
*
|
|
|
|
* LOCK channel_mutex LOCK channel_mutex
|
|
|
|
* STORE channel relid = valid_relid LOAD r1 = channel relid
|
|
|
|
* MAP_RELID channel if (r1 != INVALID_RELID)
|
|
|
|
* UNLOCK channel_mutex UNMAP_RELID channel
|
|
|
|
* UNLOCK channel_mutex
|
|
|
|
*
|
|
|
|
* Forbids: r1 == valid_relid &&
|
2021-03-10 00:21:55 -05:00
|
|
|
* channels[valid_relid] == channel
|
2020-04-05 20:15:06 -04:00
|
|
|
*
|
|
|
|
* Note. r1 can be INVALID_RELID only for an hv_sock channel.
|
|
|
|
* None of the hv_sock channels which were present before the
|
|
|
|
* suspend are re-offered upon the resume. See the WARN_ON()
|
|
|
|
* in hv_process_channel_removal().
|
|
|
|
*/
|
|
|
|
mutex_lock(&vmbus_connection.channel_mutex);
|
|
|
|
|
|
|
|
atomic_dec(&vmbus_connection.offer_in_progress);
|
|
|
|
|
2019-09-05 19:01:22 -04:00
|
|
|
WARN_ON(oldchannel->offermsg.child_relid != INVALID_RELID);
|
|
|
|
/* Fix up the relid. */
|
|
|
|
oldchannel->offermsg.child_relid = offer->child_relid;
|
|
|
|
|
2019-09-05 19:01:18 -04:00
|
|
|
offer_sz = sizeof(*offer);
|
2020-04-05 20:15:06 -04:00
|
|
|
if (memcmp(offer, &oldchannel->offermsg, offer_sz) != 0) {
|
|
|
|
/*
|
|
|
|
* This is not an error, since the host can also change
|
|
|
|
* the other field(s) of the offer, e.g. on WS RS5
|
|
|
|
* (Build 17763), the offer->connection_id of the
|
|
|
|
* Mellanox VF vmbus device can change when the host
|
|
|
|
* reoffers the device upon resume.
|
|
|
|
*/
|
|
|
|
pr_debug("vmbus offer changed: relid=%d\n",
|
|
|
|
offer->child_relid);
|
|
|
|
|
|
|
|
print_hex_dump_debug("Old vmbus offer: ",
|
|
|
|
DUMP_PREFIX_OFFSET, 16, 4,
|
|
|
|
&oldchannel->offermsg, offer_sz,
|
|
|
|
false);
|
|
|
|
print_hex_dump_debug("New vmbus offer: ",
|
|
|
|
DUMP_PREFIX_OFFSET, 16, 4,
|
|
|
|
offer, offer_sz, false);
|
|
|
|
|
|
|
|
/* Fix up the old channel. */
|
|
|
|
vmbus_setup_channel_state(oldchannel, offer);
|
2019-09-05 19:01:22 -04:00
|
|
|
}
|
2019-09-05 19:01:18 -04:00
|
|
|
|
2020-04-05 20:15:06 -04:00
|
|
|
/* Add the channel back to the array of channels. */
|
|
|
|
vmbus_channel_map_relid(oldchannel);
|
2019-09-05 19:01:22 -04:00
|
|
|
check_ready_for_resume_event();
|
|
|
|
|
2020-04-05 20:15:06 -04:00
|
|
|
mutex_unlock(&vmbus_connection.channel_mutex);
|
2019-09-05 19:01:18 -04:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2009-07-27 16:47:24 -04:00
|
|
|
/* Allocate the channel object and save this offer. */
|
2010-10-15 13:14:07 -04:00
|
|
|
newchannel = alloc_channel();
|
2010-10-15 13:14:06 -04:00
|
|
|
if (!newchannel) {
|
2017-03-13 18:57:09 -04:00
|
|
|
vmbus_release_relid(offer->child_relid);
|
2017-04-30 19:21:18 -04:00
|
|
|
atomic_dec(&vmbus_connection.offer_in_progress);
|
2011-03-29 16:58:47 -04:00
|
|
|
pr_err("Unable to allocate channel object\n");
|
2009-07-13 19:02:34 -04:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-09-05 19:01:22 -04:00
|
|
|
vmbus_setup_channel_state(newchannel, offer);
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2015-02-28 14:18:18 -05:00
|
|
|
vmbus_process_offer(newchannel);
|
2009-07-13 19:02:34 -04:00
|
|
|
}
|
|
|
|
|
2019-09-05 19:01:21 -04:00
|
|
|
static void check_ready_for_suspend_event(void)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If all the sub-channels or hv_sock channels have been cleaned up,
|
|
|
|
* then it's safe to suspend.
|
|
|
|
*/
|
|
|
|
if (atomic_dec_and_test(&vmbus_connection.nr_chan_close_on_suspend))
|
|
|
|
complete(&vmbus_connection.ready_for_suspend_event);
|
|
|
|
}
|
|
|
|
|
2010-03-04 17:11:00 -05:00
|
|
|
/*
|
2010-10-15 13:14:07 -04:00
|
|
|
* vmbus_onoffer_rescind - Rescind offer handler.
|
2009-09-01 00:47:21 -04:00
|
|
|
*
|
|
|
|
* We queue a work item to process this offer synchronously
|
|
|
|
*/
|
2010-10-15 13:14:07 -04:00
|
|
|
static void vmbus_onoffer_rescind(struct vmbus_channel_message_header *hdr)
|
2009-07-13 19:02:34 -04:00
|
|
|
{
|
2009-09-01 00:47:21 -04:00
|
|
|
struct vmbus_channel_rescind_offer *rescind;
|
2009-08-18 18:21:19 -04:00
|
|
|
struct vmbus_channel *channel;
|
2015-03-27 12:10:09 -04:00
|
|
|
struct device *dev;
|
2019-09-05 19:01:21 -04:00
|
|
|
bool clean_up_chan_for_suspend;
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2009-09-01 00:47:21 -04:00
|
|
|
rescind = (struct vmbus_channel_rescind_offer *)hdr;
|
2016-01-28 01:29:43 -05:00
|
|
|
|
2017-10-29 15:21:03 -04:00
|
|
|
trace_vmbus_onoffer_rescind(rescind);
|
|
|
|
|
2017-04-30 19:21:18 -04:00
|
|
|
/*
|
|
|
|
* The offer msg and the corresponding rescind msg
|
|
|
|
* from the host are guranteed to be ordered -
|
|
|
|
* offer comes in first and then the rescind.
|
|
|
|
* Since we process these events in work elements,
|
|
|
|
* and with preemption, we may end up processing
|
2020-04-05 20:15:05 -04:00
|
|
|
* the events out of order. We rely on the synchronization
|
|
|
|
* provided by offer_in_progress and by channel_mutex for
|
|
|
|
* ordering these events:
|
|
|
|
*
|
|
|
|
* { Initially: offer_in_progress = 1 }
|
|
|
|
*
|
|
|
|
* CPU1 CPU2
|
|
|
|
*
|
2020-04-05 20:15:06 -04:00
|
|
|
* [vmbus_onoffer()] [vmbus_onoffer_rescind()]
|
2020-04-05 20:15:05 -04:00
|
|
|
*
|
|
|
|
* LOCK channel_mutex WAIT_ON offer_in_progress == 0
|
|
|
|
* DECREMENT offer_in_progress LOCK channel_mutex
|
2020-04-05 20:15:06 -04:00
|
|
|
* STORE channels[] LOAD channels[]
|
2020-04-05 20:15:05 -04:00
|
|
|
* UNLOCK channel_mutex UNLOCK channel_mutex
|
|
|
|
*
|
2020-04-05 20:15:06 -04:00
|
|
|
* Forbids: CPU2's LOAD from *not* seeing CPU1's STORE
|
2017-04-30 19:21:18 -04:00
|
|
|
*/
|
|
|
|
|
|
|
|
while (atomic_read(&vmbus_connection.offer_in_progress) != 0) {
|
|
|
|
/*
|
|
|
|
* We wait here until any channel offer is currently
|
|
|
|
* being processed.
|
|
|
|
*/
|
|
|
|
msleep(1);
|
|
|
|
}
|
|
|
|
|
2016-01-28 01:29:43 -05:00
|
|
|
mutex_lock(&vmbus_connection.channel_mutex);
|
2015-03-27 12:10:09 -04:00
|
|
|
channel = relid2channel(rescind->child_relid);
|
2020-12-09 02:08:26 -05:00
|
|
|
if (channel != NULL) {
|
|
|
|
/*
|
|
|
|
* Guarantee that no other instance of vmbus_onoffer_rescind()
|
|
|
|
* has got a reference to the channel object. Synchronize on
|
|
|
|
* &vmbus_connection.channel_mutex.
|
|
|
|
*/
|
|
|
|
if (channel->rescind_ref) {
|
|
|
|
mutex_unlock(&vmbus_connection.channel_mutex);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
channel->rescind_ref = true;
|
|
|
|
}
|
2017-04-30 19:21:18 -04:00
|
|
|
mutex_unlock(&vmbus_connection.channel_mutex);
|
2011-03-29 16:58:44 -04:00
|
|
|
|
2015-02-28 14:18:18 -05:00
|
|
|
if (channel == NULL) {
|
2015-12-14 19:01:50 -05:00
|
|
|
/*
|
2017-04-30 19:21:18 -04:00
|
|
|
* We failed in processing the offer message;
|
|
|
|
* we would have cleaned up the relid in that
|
|
|
|
* failure path.
|
2015-12-14 19:01:50 -05:00
|
|
|
*/
|
2017-04-30 19:21:18 -04:00
|
|
|
return;
|
2015-02-28 14:18:18 -05:00
|
|
|
}
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2019-09-05 19:01:21 -04:00
|
|
|
clean_up_chan_for_suspend = is_hvsock_channel(channel) ||
|
|
|
|
is_sub_channel(channel);
|
2018-08-01 23:08:23 -04:00
|
|
|
/*
|
|
|
|
* Before setting channel->rescind in vmbus_rescind_cleanup(), we
|
|
|
|
* should make sure the channel callback is not running any more.
|
|
|
|
*/
|
|
|
|
vmbus_reset_channel_cb(channel);
|
|
|
|
|
2017-08-11 13:03:59 -04:00
|
|
|
/*
|
|
|
|
* Now wait for offer handling to complete.
|
|
|
|
*/
|
2017-11-14 08:53:33 -05:00
|
|
|
vmbus_rescind_cleanup(channel);
|
2017-08-11 13:03:59 -04:00
|
|
|
while (READ_ONCE(channel->probe_done) == false) {
|
|
|
|
/*
|
|
|
|
* We wait here until any channel offer is currently
|
|
|
|
* being processed.
|
|
|
|
*/
|
|
|
|
msleep(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* At this point, the rescind handling can proceed safely.
|
|
|
|
*/
|
|
|
|
|
2015-03-27 12:10:09 -04:00
|
|
|
if (channel->device_obj) {
|
2016-01-28 01:29:42 -05:00
|
|
|
if (channel->chn_rescind_callback) {
|
|
|
|
channel->chn_rescind_callback(channel);
|
2019-09-05 19:01:21 -04:00
|
|
|
|
|
|
|
if (clean_up_chan_for_suspend)
|
|
|
|
check_ready_for_suspend_event();
|
|
|
|
|
2017-04-30 19:21:18 -04:00
|
|
|
return;
|
2016-01-28 01:29:42 -05:00
|
|
|
}
|
2015-03-27 12:10:09 -04:00
|
|
|
/*
|
|
|
|
* We will have to unregister this device from the
|
|
|
|
* driver core.
|
|
|
|
*/
|
|
|
|
dev = get_device(&channel->device_obj->device);
|
|
|
|
if (dev) {
|
|
|
|
vmbus_device_unregister(channel->device_obj);
|
|
|
|
put_device(dev);
|
|
|
|
}
|
2020-12-09 02:08:25 -05:00
|
|
|
} else if (channel->primary_channel != NULL) {
|
2017-04-30 19:21:18 -04:00
|
|
|
/*
|
|
|
|
* Sub-channel is being rescinded. Following is the channel
|
|
|
|
* close sequence when initiated from the driveri (refer to
|
|
|
|
* vmbus_close() for details):
|
|
|
|
* 1. Close all sub-channels first
|
|
|
|
* 2. Then close the primary channel.
|
|
|
|
*/
|
2017-09-30 00:09:36 -04:00
|
|
|
mutex_lock(&vmbus_connection.channel_mutex);
|
2017-04-30 19:21:18 -04:00
|
|
|
if (channel->state == CHANNEL_OPEN_STATE) {
|
|
|
|
/*
|
|
|
|
* The channel is currently not open;
|
|
|
|
* it is safe for us to cleanup the channel.
|
|
|
|
*/
|
2018-09-14 12:10:15 -04:00
|
|
|
hv_process_channel_removal(channel);
|
2017-11-14 08:53:33 -05:00
|
|
|
} else {
|
|
|
|
complete(&channel->rescind_event);
|
2017-04-30 19:21:18 -04:00
|
|
|
}
|
2017-09-30 00:09:36 -04:00
|
|
|
mutex_unlock(&vmbus_connection.channel_mutex);
|
2017-04-30 19:21:18 -04:00
|
|
|
}
|
2019-09-05 19:01:21 -04:00
|
|
|
|
|
|
|
/* The "channel" may have been freed. Do not access it any longer. */
|
|
|
|
|
|
|
|
if (clean_up_chan_for_suspend)
|
|
|
|
check_ready_for_suspend_event();
|
2016-01-28 01:29:43 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
void vmbus_hvsock_device_unregister(struct vmbus_channel *channel)
|
|
|
|
{
|
|
|
|
BUG_ON(!is_hvsock_channel(channel));
|
|
|
|
|
2017-10-18 05:08:40 -04:00
|
|
|
/* We always get a rescind msg when a connection is closed. */
|
|
|
|
while (!READ_ONCE(channel->probe_done) || !READ_ONCE(channel->rescind))
|
|
|
|
msleep(1);
|
|
|
|
|
2016-01-28 01:29:43 -05:00
|
|
|
vmbus_device_unregister(channel->device_obj);
|
2009-07-13 19:02:34 -04:00
|
|
|
}
|
2016-01-28 01:29:43 -05:00
|
|
|
EXPORT_SYMBOL_GPL(vmbus_hvsock_device_unregister);
|
|
|
|
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2010-03-04 17:11:00 -05:00
|
|
|
/*
|
2010-10-15 13:14:07 -04:00
|
|
|
* vmbus_onoffers_delivered -
|
|
|
|
* This is invoked when all offers have been delivered.
|
2009-09-01 00:47:21 -04:00
|
|
|
*
|
|
|
|
* Nothing to do here.
|
|
|
|
*/
|
2010-10-15 13:14:07 -04:00
|
|
|
static void vmbus_onoffers_delivered(
|
2009-09-01 00:47:21 -04:00
|
|
|
struct vmbus_channel_message_header *hdr)
|
2009-07-13 19:02:34 -04:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2010-03-04 17:11:00 -05:00
|
|
|
/*
|
2010-10-15 13:14:07 -04:00
|
|
|
* vmbus_onopen_result - Open result handler.
|
2009-09-01 00:47:21 -04:00
|
|
|
*
|
|
|
|
* This is invoked when we received a response to our channel open request.
|
|
|
|
* Find the matching request, copy the response and signal the requesting
|
|
|
|
* thread.
|
|
|
|
*/
|
2010-10-15 13:14:07 -04:00
|
|
|
static void vmbus_onopen_result(struct vmbus_channel_message_header *hdr)
|
2009-07-13 19:02:34 -04:00
|
|
|
{
|
2009-09-01 00:47:21 -04:00
|
|
|
struct vmbus_channel_open_result *result;
|
2010-10-15 13:14:06 -04:00
|
|
|
struct vmbus_channel_msginfo *msginfo;
|
|
|
|
struct vmbus_channel_message_header *requestheader;
|
|
|
|
struct vmbus_channel_open_channel *openmsg;
|
2009-07-15 17:56:45 -04:00
|
|
|
unsigned long flags;
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2009-09-01 00:47:21 -04:00
|
|
|
result = (struct vmbus_channel_open_result *)hdr;
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2017-10-29 15:21:04 -04:00
|
|
|
trace_vmbus_onopen_result(result);
|
|
|
|
|
2009-09-01 00:47:21 -04:00
|
|
|
/*
|
|
|
|
* Find the open msg, copy the result and signal/unblock the wait event
|
|
|
|
*/
|
2011-01-26 15:12:07 -05:00
|
|
|
spin_lock_irqsave(&vmbus_connection.channelmsg_lock, flags);
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2011-02-18 15:39:57 -05:00
|
|
|
list_for_each_entry(msginfo, &vmbus_connection.chn_msg_list,
|
|
|
|
msglistentry) {
|
2010-10-15 13:14:06 -04:00
|
|
|
requestheader =
|
2010-11-08 17:04:38 -05:00
|
|
|
(struct vmbus_channel_message_header *)msginfo->msg;
|
2010-10-15 13:14:06 -04:00
|
|
|
|
2010-11-08 17:04:38 -05:00
|
|
|
if (requestheader->msgtype == CHANNELMSG_OPENCHANNEL) {
|
2010-10-15 13:14:06 -04:00
|
|
|
openmsg =
|
2010-11-08 17:04:38 -05:00
|
|
|
(struct vmbus_channel_open_channel *)msginfo->msg;
|
|
|
|
if (openmsg->child_relid == result->child_relid &&
|
|
|
|
openmsg->openid == result->openid) {
|
|
|
|
memcpy(&msginfo->response.open_result,
|
2009-09-01 00:47:21 -04:00
|
|
|
result,
|
2011-05-10 10:55:39 -04:00
|
|
|
sizeof(
|
|
|
|
struct vmbus_channel_open_result));
|
|
|
|
complete(&msginfo->waitevent);
|
2009-07-13 19:02:34 -04:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2011-01-26 15:12:07 -05:00
|
|
|
spin_unlock_irqrestore(&vmbus_connection.channelmsg_lock, flags);
|
2009-07-13 19:02:34 -04:00
|
|
|
}
|
|
|
|
|
2010-03-04 17:11:00 -05:00
|
|
|
/*
|
2010-10-15 13:14:07 -04:00
|
|
|
* vmbus_ongpadl_created - GPADL created handler.
|
2009-09-01 00:47:21 -04:00
|
|
|
*
|
|
|
|
* This is invoked when we received a response to our gpadl create request.
|
|
|
|
* Find the matching request, copy the response and signal the requesting
|
|
|
|
* thread.
|
|
|
|
*/
|
2010-10-15 13:14:07 -04:00
|
|
|
static void vmbus_ongpadl_created(struct vmbus_channel_message_header *hdr)
|
2009-07-13 19:02:34 -04:00
|
|
|
{
|
2010-10-15 13:14:06 -04:00
|
|
|
struct vmbus_channel_gpadl_created *gpadlcreated;
|
|
|
|
struct vmbus_channel_msginfo *msginfo;
|
|
|
|
struct vmbus_channel_message_header *requestheader;
|
|
|
|
struct vmbus_channel_gpadl_header *gpadlheader;
|
2009-07-15 17:56:45 -04:00
|
|
|
unsigned long flags;
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2010-10-15 13:14:06 -04:00
|
|
|
gpadlcreated = (struct vmbus_channel_gpadl_created *)hdr;
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2017-10-29 15:21:05 -04:00
|
|
|
trace_vmbus_ongpadl_created(gpadlcreated);
|
|
|
|
|
2009-09-01 00:47:21 -04:00
|
|
|
/*
|
|
|
|
* Find the establish msg, copy the result and signal/unblock the wait
|
|
|
|
* event
|
|
|
|
*/
|
2011-01-26 15:12:07 -05:00
|
|
|
spin_lock_irqsave(&vmbus_connection.channelmsg_lock, flags);
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2011-02-18 15:39:57 -05:00
|
|
|
list_for_each_entry(msginfo, &vmbus_connection.chn_msg_list,
|
|
|
|
msglistentry) {
|
2010-10-15 13:14:06 -04:00
|
|
|
requestheader =
|
2010-11-08 17:04:38 -05:00
|
|
|
(struct vmbus_channel_message_header *)msginfo->msg;
|
2010-10-15 13:14:06 -04:00
|
|
|
|
2010-11-08 17:04:38 -05:00
|
|
|
if (requestheader->msgtype == CHANNELMSG_GPADL_HEADER) {
|
2010-10-15 13:14:06 -04:00
|
|
|
gpadlheader =
|
|
|
|
(struct vmbus_channel_gpadl_header *)requestheader;
|
|
|
|
|
2010-11-08 17:04:38 -05:00
|
|
|
if ((gpadlcreated->child_relid ==
|
|
|
|
gpadlheader->child_relid) &&
|
|
|
|
(gpadlcreated->gpadl == gpadlheader->gpadl)) {
|
|
|
|
memcpy(&msginfo->response.gpadl_created,
|
2010-10-15 13:14:06 -04:00
|
|
|
gpadlcreated,
|
2011-05-10 10:55:39 -04:00
|
|
|
sizeof(
|
|
|
|
struct vmbus_channel_gpadl_created));
|
|
|
|
complete(&msginfo->waitevent);
|
2009-07-13 19:02:34 -04:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2011-01-26 15:12:07 -05:00
|
|
|
spin_unlock_irqrestore(&vmbus_connection.channelmsg_lock, flags);
|
2009-07-13 19:02:34 -04:00
|
|
|
}
|
|
|
|
|
2021-04-16 10:34:48 -04:00
|
|
|
/*
|
|
|
|
* vmbus_onmodifychannel_response - Modify Channel response handler.
|
|
|
|
*
|
|
|
|
* This is invoked when we received a response to our channel modify request.
|
|
|
|
* Find the matching request, copy the response and signal the requesting thread.
|
|
|
|
*/
|
|
|
|
static void vmbus_onmodifychannel_response(struct vmbus_channel_message_header *hdr)
|
|
|
|
{
|
|
|
|
struct vmbus_channel_modifychannel_response *response;
|
|
|
|
struct vmbus_channel_msginfo *msginfo;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
response = (struct vmbus_channel_modifychannel_response *)hdr;
|
|
|
|
|
|
|
|
trace_vmbus_onmodifychannel_response(response);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the modify msg, copy the response and signal/unblock the wait event.
|
|
|
|
*/
|
|
|
|
spin_lock_irqsave(&vmbus_connection.channelmsg_lock, flags);
|
|
|
|
|
|
|
|
list_for_each_entry(msginfo, &vmbus_connection.chn_msg_list, msglistentry) {
|
|
|
|
struct vmbus_channel_message_header *responseheader =
|
|
|
|
(struct vmbus_channel_message_header *)msginfo->msg;
|
|
|
|
|
|
|
|
if (responseheader->msgtype == CHANNELMSG_MODIFYCHANNEL) {
|
|
|
|
struct vmbus_channel_modifychannel *modifymsg;
|
|
|
|
|
|
|
|
modifymsg = (struct vmbus_channel_modifychannel *)msginfo->msg;
|
|
|
|
if (modifymsg->child_relid == response->child_relid) {
|
|
|
|
memcpy(&msginfo->response.modify_response, response,
|
|
|
|
sizeof(*response));
|
|
|
|
complete(&msginfo->waitevent);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
spin_unlock_irqrestore(&vmbus_connection.channelmsg_lock, flags);
|
|
|
|
}
|
|
|
|
|
2010-03-04 17:11:00 -05:00
|
|
|
/*
|
2010-10-15 13:14:07 -04:00
|
|
|
* vmbus_ongpadl_torndown - GPADL torndown handler.
|
2009-09-01 00:47:21 -04:00
|
|
|
*
|
|
|
|
* This is invoked when we received a response to our gpadl teardown request.
|
|
|
|
* Find the matching request, copy the response and signal the requesting
|
|
|
|
* thread.
|
|
|
|
*/
|
2010-10-15 13:14:07 -04:00
|
|
|
static void vmbus_ongpadl_torndown(
|
2009-09-01 00:47:21 -04:00
|
|
|
struct vmbus_channel_message_header *hdr)
|
2009-07-13 19:02:34 -04:00
|
|
|
{
|
2010-10-15 13:14:06 -04:00
|
|
|
struct vmbus_channel_gpadl_torndown *gpadl_torndown;
|
|
|
|
struct vmbus_channel_msginfo *msginfo;
|
|
|
|
struct vmbus_channel_message_header *requestheader;
|
|
|
|
struct vmbus_channel_gpadl_teardown *gpadl_teardown;
|
2009-07-15 17:56:45 -04:00
|
|
|
unsigned long flags;
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2010-10-15 13:14:06 -04:00
|
|
|
gpadl_torndown = (struct vmbus_channel_gpadl_torndown *)hdr;
|
2009-09-01 00:47:21 -04:00
|
|
|
|
2017-10-29 15:21:06 -04:00
|
|
|
trace_vmbus_ongpadl_torndown(gpadl_torndown);
|
|
|
|
|
2009-09-01 00:47:21 -04:00
|
|
|
/*
|
|
|
|
* Find the open msg, copy the result and signal/unblock the wait event
|
|
|
|
*/
|
2011-01-26 15:12:07 -05:00
|
|
|
spin_lock_irqsave(&vmbus_connection.channelmsg_lock, flags);
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2011-02-18 15:39:57 -05:00
|
|
|
list_for_each_entry(msginfo, &vmbus_connection.chn_msg_list,
|
|
|
|
msglistentry) {
|
2010-10-15 13:14:06 -04:00
|
|
|
requestheader =
|
2010-11-08 17:04:38 -05:00
|
|
|
(struct vmbus_channel_message_header *)msginfo->msg;
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2010-11-08 17:04:38 -05:00
|
|
|
if (requestheader->msgtype == CHANNELMSG_GPADL_TEARDOWN) {
|
2010-10-15 13:14:06 -04:00
|
|
|
gpadl_teardown =
|
|
|
|
(struct vmbus_channel_gpadl_teardown *)requestheader;
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2010-11-08 17:04:38 -05:00
|
|
|
if (gpadl_torndown->gpadl == gpadl_teardown->gpadl) {
|
|
|
|
memcpy(&msginfo->response.gpadl_torndown,
|
2010-10-15 13:14:06 -04:00
|
|
|
gpadl_torndown,
|
2011-05-10 10:55:39 -04:00
|
|
|
sizeof(
|
|
|
|
struct vmbus_channel_gpadl_torndown));
|
|
|
|
complete(&msginfo->waitevent);
|
2009-07-13 19:02:34 -04:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2011-01-26 15:12:07 -05:00
|
|
|
spin_unlock_irqrestore(&vmbus_connection.channelmsg_lock, flags);
|
2009-07-13 19:02:34 -04:00
|
|
|
}
|
|
|
|
|
2010-03-04 17:11:00 -05:00
|
|
|
/*
|
2010-10-15 13:14:07 -04:00
|
|
|
* vmbus_onversion_response - Version response handler
|
2009-09-01 00:47:21 -04:00
|
|
|
*
|
|
|
|
* This is invoked when we received a response to our initiate contact request.
|
|
|
|
* Find the matching request, copy the response and signal the requesting
|
|
|
|
* thread.
|
|
|
|
*/
|
2010-10-15 13:14:07 -04:00
|
|
|
static void vmbus_onversion_response(
|
2009-09-01 00:47:21 -04:00
|
|
|
struct vmbus_channel_message_header *hdr)
|
2009-07-13 19:02:34 -04:00
|
|
|
{
|
2010-10-15 13:14:06 -04:00
|
|
|
struct vmbus_channel_msginfo *msginfo;
|
|
|
|
struct vmbus_channel_message_header *requestheader;
|
|
|
|
struct vmbus_channel_version_response *version_response;
|
2009-07-15 17:56:45 -04:00
|
|
|
unsigned long flags;
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2010-10-15 13:14:06 -04:00
|
|
|
version_response = (struct vmbus_channel_version_response *)hdr;
|
2017-10-29 15:21:07 -04:00
|
|
|
|
|
|
|
trace_vmbus_onversion_response(version_response);
|
|
|
|
|
2011-01-26 15:12:07 -05:00
|
|
|
spin_lock_irqsave(&vmbus_connection.channelmsg_lock, flags);
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2011-02-18 15:39:57 -05:00
|
|
|
list_for_each_entry(msginfo, &vmbus_connection.chn_msg_list,
|
|
|
|
msglistentry) {
|
2010-10-15 13:14:06 -04:00
|
|
|
requestheader =
|
2010-11-08 17:04:38 -05:00
|
|
|
(struct vmbus_channel_message_header *)msginfo->msg;
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2010-11-08 17:04:38 -05:00
|
|
|
if (requestheader->msgtype ==
|
|
|
|
CHANNELMSG_INITIATE_CONTACT) {
|
|
|
|
memcpy(&msginfo->response.version_response,
|
2010-10-15 13:14:06 -04:00
|
|
|
version_response,
|
2009-09-01 00:47:21 -04:00
|
|
|
sizeof(struct vmbus_channel_version_response));
|
2011-05-10 10:55:39 -04:00
|
|
|
complete(&msginfo->waitevent);
|
2009-07-13 19:02:34 -04:00
|
|
|
}
|
|
|
|
}
|
2011-01-26 15:12:07 -05:00
|
|
|
spin_unlock_irqrestore(&vmbus_connection.channelmsg_lock, flags);
|
2009-07-13 19:02:34 -04:00
|
|
|
}
|
|
|
|
|
2009-09-01 00:51:50 -04:00
|
|
|
/* Channel message dispatch table */
|
2017-03-04 20:27:16 -05:00
|
|
|
const struct vmbus_channel_message_table_entry
|
|
|
|
channel_message_table[CHANNELMSG_COUNT] = {
|
2020-04-06 06:43:26 -04:00
|
|
|
{ CHANNELMSG_INVALID, 0, NULL, 0},
|
|
|
|
{ CHANNELMSG_OFFERCHANNEL, 0, vmbus_onoffer,
|
|
|
|
sizeof(struct vmbus_channel_offer_channel)},
|
|
|
|
{ CHANNELMSG_RESCIND_CHANNELOFFER, 0, vmbus_onoffer_rescind,
|
|
|
|
sizeof(struct vmbus_channel_rescind_offer) },
|
|
|
|
{ CHANNELMSG_REQUESTOFFERS, 0, NULL, 0},
|
|
|
|
{ CHANNELMSG_ALLOFFERS_DELIVERED, 1, vmbus_onoffers_delivered, 0},
|
|
|
|
{ CHANNELMSG_OPENCHANNEL, 0, NULL, 0},
|
|
|
|
{ CHANNELMSG_OPENCHANNEL_RESULT, 1, vmbus_onopen_result,
|
|
|
|
sizeof(struct vmbus_channel_open_result)},
|
|
|
|
{ CHANNELMSG_CLOSECHANNEL, 0, NULL, 0},
|
|
|
|
{ CHANNELMSG_GPADL_HEADER, 0, NULL, 0},
|
|
|
|
{ CHANNELMSG_GPADL_BODY, 0, NULL, 0},
|
|
|
|
{ CHANNELMSG_GPADL_CREATED, 1, vmbus_ongpadl_created,
|
|
|
|
sizeof(struct vmbus_channel_gpadl_created)},
|
|
|
|
{ CHANNELMSG_GPADL_TEARDOWN, 0, NULL, 0},
|
|
|
|
{ CHANNELMSG_GPADL_TORNDOWN, 1, vmbus_ongpadl_torndown,
|
|
|
|
sizeof(struct vmbus_channel_gpadl_torndown) },
|
|
|
|
{ CHANNELMSG_RELID_RELEASED, 0, NULL, 0},
|
|
|
|
{ CHANNELMSG_INITIATE_CONTACT, 0, NULL, 0},
|
|
|
|
{ CHANNELMSG_VERSION_RESPONSE, 1, vmbus_onversion_response,
|
|
|
|
sizeof(struct vmbus_channel_version_response)},
|
|
|
|
{ CHANNELMSG_UNLOAD, 0, NULL, 0},
|
|
|
|
{ CHANNELMSG_UNLOAD_RESPONSE, 1, vmbus_unload_response, 0},
|
|
|
|
{ CHANNELMSG_18, 0, NULL, 0},
|
|
|
|
{ CHANNELMSG_19, 0, NULL, 0},
|
|
|
|
{ CHANNELMSG_20, 0, NULL, 0},
|
|
|
|
{ CHANNELMSG_TL_CONNECT_REQUEST, 0, NULL, 0},
|
2020-04-05 20:15:13 -04:00
|
|
|
{ CHANNELMSG_MODIFYCHANNEL, 0, NULL, 0},
|
2020-04-06 06:43:26 -04:00
|
|
|
{ CHANNELMSG_TL_CONNECT_RESULT, 0, NULL, 0},
|
2021-04-16 10:34:48 -04:00
|
|
|
{ CHANNELMSG_MODIFYCHANNEL_RESPONSE, 1, vmbus_onmodifychannel_response,
|
|
|
|
sizeof(struct vmbus_channel_modifychannel_response)},
|
2009-09-01 00:51:50 -04:00
|
|
|
};
|
|
|
|
|
2010-03-04 17:11:00 -05:00
|
|
|
/*
|
2010-10-15 13:14:07 -04:00
|
|
|
* vmbus_onmessage - Handler for channel protocol messages.
|
2009-09-01 00:47:21 -04:00
|
|
|
*
|
|
|
|
* This is invoked in the vmbus worker thread context.
|
|
|
|
*/
|
2020-04-06 06:41:52 -04:00
|
|
|
void vmbus_onmessage(struct vmbus_channel_message_header *hdr)
|
2009-07-13 19:02:34 -04:00
|
|
|
{
|
2017-10-29 15:21:01 -04:00
|
|
|
trace_vmbus_on_message(hdr);
|
|
|
|
|
2020-01-19 18:29:22 -05:00
|
|
|
/*
|
|
|
|
* vmbus_on_msg_dpc() makes sure the hdr->msgtype here can not go
|
|
|
|
* out of bound and the message_handler pointer can not be NULL.
|
|
|
|
*/
|
|
|
|
channel_message_table[hdr->msgtype].message_handler(hdr);
|
2009-07-13 19:02:34 -04:00
|
|
|
}
|
|
|
|
|
2010-03-04 17:11:00 -05:00
|
|
|
/*
|
2010-10-15 13:14:07 -04:00
|
|
|
* vmbus_request_offers - Send a request to get all our pending offers.
|
2009-09-01 00:47:21 -04:00
|
|
|
*/
|
2010-10-15 13:14:07 -04:00
|
|
|
int vmbus_request_offers(void)
|
2009-07-13 19:02:34 -04:00
|
|
|
{
|
2009-08-26 18:16:04 -04:00
|
|
|
struct vmbus_channel_message_header *msg;
|
2010-10-15 13:14:06 -04:00
|
|
|
struct vmbus_channel_msginfo *msginfo;
|
2015-02-27 14:26:02 -05:00
|
|
|
int ret;
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2022-01-05 14:27:46 -05:00
|
|
|
msginfo = kzalloc(sizeof(*msginfo) +
|
2009-09-01 00:47:21 -04:00
|
|
|
sizeof(struct vmbus_channel_message_header),
|
|
|
|
GFP_KERNEL);
|
2010-10-15 13:14:06 -04:00
|
|
|
if (!msginfo)
|
2010-05-05 15:27:31 -04:00
|
|
|
return -ENOMEM;
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2010-11-08 17:04:38 -05:00
|
|
|
msg = (struct vmbus_channel_message_header *)msginfo->msg;
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2010-11-08 17:04:38 -05:00
|
|
|
msg->msgtype = CHANNELMSG_REQUESTOFFERS;
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2016-12-07 04:16:24 -05:00
|
|
|
ret = vmbus_post_msg(msg, sizeof(struct vmbus_channel_message_header),
|
|
|
|
true);
|
2017-10-29 15:21:08 -04:00
|
|
|
|
|
|
|
trace_vmbus_request_offers(ret);
|
|
|
|
|
2009-09-01 00:47:21 -04:00
|
|
|
if (ret != 0) {
|
2011-03-29 16:58:47 -04:00
|
|
|
pr_err("Unable to request offers - %d\n", ret);
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2011-02-11 12:59:43 -05:00
|
|
|
goto cleanup;
|
|
|
|
}
|
2009-07-13 19:02:34 -04:00
|
|
|
|
2011-02-11 12:59:43 -05:00
|
|
|
cleanup:
|
2011-03-13 00:29:00 -05:00
|
|
|
kfree(msginfo);
|
2009-07-13 19:02:34 -04:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2013-05-23 15:02:32 -04:00
|
|
|
void vmbus_set_sc_create_callback(struct vmbus_channel *primary_channel,
|
|
|
|
void (*sc_cr_cb)(struct vmbus_channel *new_sc))
|
|
|
|
{
|
|
|
|
primary_channel->sc_creation_callback = sc_cr_cb;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(vmbus_set_sc_create_callback);
|
|
|
|
|
2016-01-28 01:29:42 -05:00
|
|
|
void vmbus_set_chn_rescind_callback(struct vmbus_channel *channel,
|
|
|
|
void (*chn_rescind_cb)(struct vmbus_channel *))
|
|
|
|
{
|
|
|
|
channel->chn_rescind_callback = chn_rescind_cb;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(vmbus_set_chn_rescind_callback);
|