Messages in this thread | | | From | Dexuan Cui <> | Subject | RE: [PATCH] Drivers: hv: vmbus: fix the race when querying & updating the percpu list | Date | Tue, 17 May 2016 08:35:00 +0000 |
| |
> From: Vitaly Kuznetsov [mailto:vkuznets@redhat.com] > Sent: Tuesday, May 17, 2016 16:15 > To: Dexuan Cui <decui@microsoft.com> > Cc: gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org; driverdev- > devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com; > jasowang@redhat.com; KY Srinivasan <kys@microsoft.com>; Haiyang Zhang > <haiyangz@microsoft.com> > Subject: Re: [PATCH] Drivers: hv: vmbus: fix the race when querying & updating > the percpu list > > Dexuan Cui <decui@microsoft.com> writes: > > > There is a rare race when we remove an entry from the global list > > hv_context.percpu_list[cpu] in hv_process_channel_removal() -> > > percpu_channel_deq() -> list_del(): at this time, if vmbus_on_event() -> > > process_chn_event() -> pcpu_relid2channel() is trying to query the list, > > we can get the general protection fault: > >... > > > > We can resolve the issue by disabling the tasklet when updating the list. > > > > @@ -418,6 +413,7 @@ static void vmbus_process_offer(struct > vmbus_channel *newchannel) > > percpu_channel_enq(newchannel); > > put_cpu(); > > } > > + tasklet_enable(tasklet); > > Do we need to do tasklet_schedule() to make sure there are no events > pending? This is probably not a big issue as some other event will > trigger scheduling but in some corner cases it may bite. Same question > applies to the code below and to vmbus_close_internal().
Hi Vitaly, Thanks for spotting this! I think you're correct. I'll add tasklet_schedul() before the tasklet_enable() in the 2 places.
Thanks, -- Dexuan
| |