[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <MW2PR2101MB1052C380E026F86F34C19D50D7B40@MW2PR2101MB1052.namprd21.prod.outlook.com>
Date: Fri, 22 May 2020 18:34:14 +0000
From: Michael Kelley <mikelley@...rosoft.com>
To: "Andrea Parri (Microsoft)" <parri.andrea@...il.com>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: KY Srinivasan <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Stephen Hemminger <sthemmin@...rosoft.com>,
Wei Liu <wei.liu@...nel.org>
Subject: RE: [PATCH 1/2] Drivers: hv: vmbus: Resolve race between
init_vp_index() and CPU hotplug
From: Andrea Parri (Microsoft) <parri.andrea@...il.com> Sent: Friday, May 22, 2020 10:19 AM
>
> vmbus_process_offer() does two things (among others):
>
> 1) first, it sets the channel's target CPU with cpu_hotplug_lock;
> 2) it then adds the channel to the channel list(s) with channel_mutex.
>
> Since cpu_hotplug_lock is released before (2), the channel's target CPU
> (as designated in (1)) can be deemed "free" by hv_synic_cleanup() and go
> offline before the channel is added to the list.
>
> Fix the race condition by "extending" the cpu_hotplug_lock critical
> section to include (2) (and (1)), nesting the channel_mutex critical
> section within the cpu_hotplug_lock critical section as done elsewhere
> (hv_synic_cleanup(), target_cpu_store()) in the hyperv drivers code.
>
> Move even further by extending the channel_mutex critical section to
> include (1) (and (2)): this change allows to remove (the now redundant)
> bind_channel_to_cpu_lock, and generally simplifies the handling of the
> target CPUs (that are now always modified with channel_mutex held).
>
> Fixes: d570aec0f2154e ("Drivers: hv: vmbus: Synchronize init_vp_index() vs. CPU hotplug")
> Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@...il.com>
> ---
> drivers/hv/channel_mgmt.c | 46 +++++++++++++++------------------------
> 1 file changed, 18 insertions(+), 28 deletions(-)
Reviewed-by: Michael Kelley <mikelley@...rosoft.com>
Powered by blists - more mailing lists