diff options
| author | Andrea Parri (Microsoft) <parri.andrea@gmail.com> | 2020-04-06 02:15:05 +0200 |
|---|---|---|
| committer | Wei Liu <wei.liu@kernel.org> | 2020-04-23 13:17:11 +0000 |
| commit | b9fa1b8797dcb579a9642a502769e1a5c3adc0d2 (patch) | |
| tree | 30c43007fbb52fdf9fe1346a0a348e881aca7c00 /drivers/hv/channel_mgmt.c | |
| parent | 8a857c55420f29da4fc131adc22b12d474c48f4c (diff) | |
| download | lwn-b9fa1b8797dcb579a9642a502769e1a5c3adc0d2.tar.gz lwn-b9fa1b8797dcb579a9642a502769e1a5c3adc0d2.zip | |
Drivers: hv: vmbus: Don't bind the offer&rescind works to a specific CPU
The offer and rescind works are currently scheduled on the so called
"connect CPU". However, this is not really needed: we can synchronize
the works by relying on the usage of the offer_in_progress counter and
of the channel_mutex mutex. This synchronization is already in place.
So, remove this unnecessary "bind to the connect CPU" constraint and
update the inline comments accordingly.
Suggested-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Link: https://lore.kernel.org/r/20200406001514.19876-3-parri.andrea@gmail.com
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Diffstat (limited to 'drivers/hv/channel_mgmt.c')
| -rw-r--r-- | drivers/hv/channel_mgmt.c | 21 |
1 files changed, 16 insertions, 5 deletions
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c index 3a5700c8486a..0ced32ef2715 100644 --- a/drivers/hv/channel_mgmt.c +++ b/drivers/hv/channel_mgmt.c @@ -1028,11 +1028,22 @@ static void vmbus_onoffer_rescind(struct vmbus_channel_message_header *hdr) * offer comes in first and then the rescind. * Since we process these events in work elements, * and with preemption, we may end up processing - * the events out of order. Given that we handle these - * work elements on the same CPU, this is possible only - * in the case of preemption. In any case wait here - * until the offer processing has moved beyond the - * point where the channel is discoverable. + * 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 + * + * [vmbus_process_offer()] [vmbus_onoffer_rescind()] + * + * LOCK channel_mutex WAIT_ON offer_in_progress == 0 + * DECREMENT offer_in_progress LOCK channel_mutex + * INSERT chn_list SEARCH chn_list + * UNLOCK channel_mutex UNLOCK channel_mutex + * + * Forbids: CPU2's SEARCH from *not* seeing CPU1's INSERT */ while (atomic_read(&vmbus_connection.offer_in_progress) != 0) { |