> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Tuesday, May 17, 2016 16:15 > To: Dexuan Cui <de...@microsoft.com> > Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; driverdev- > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > jasow...@redhat.com; KY Srinivasan <k...@microsoft.com>; Haiyang Zhang > <haiya...@microsoft.com> > Subject: Re: [PATCH] Drivers: hv: vmbus: fix the race when querying & updating > the percpu list > > Dexuan Cui <de...@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 _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
