> From: Vitaly Kuznetsov [mailto:[email protected]] > Sent: Tuesday, May 17, 2016 16:15 > To: Dexuan Cui <[email protected]> > Cc: [email protected]; [email protected]; driverdev- > [email protected]; [email protected]; [email protected]; > [email protected]; KY Srinivasan <[email protected]>; Haiyang Zhang > <[email protected]> > Subject: Re: [PATCH] Drivers: hv: vmbus: fix the race when querying & updating > the percpu list > > Dexuan Cui <[email protected]> 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 [email protected] http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
