> From: Vitaly Kuznetsov [mailto:vkuznets@xxxxxxxxxx] > Sent: Tuesday, May 17, 2016 16:15 > To: Dexuan Cui <decui@xxxxxxxxxxxxx> > Cc: gregkh@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; driverdev- > devel@xxxxxxxxxxxxxxxxxxxxxx; olaf@xxxxxxxxx; apw@xxxxxxxxxxxxx; > jasowang@xxxxxxxxxx; KY Srinivasan <kys@xxxxxxxxxxxxx>; Haiyang Zhang > <haiyangz@xxxxxxxxxxxxx> > Subject: Re: [PATCH] Drivers: hv: vmbus: fix the race when querying & updating > the percpu list > > Dexuan Cui <decui@xxxxxxxxxxxxx> 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 devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
