[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] RE: [PATCH]CPUFREQ: Fix two racing issues during cpu hotplug
On Monday, 2010-4-12 2:10 PM, Keir Fraser wrote: > On 12/04/2010 05:45, "Wei, Gang" <gang.wei@xxxxxxxxx> wrote: > >> Move cpufreq_del_cpu() call into __cpu_disable to eliminate racing >> with dbs timer handler on policy & drv_data. Put it after >> local_irq_enable because xmalloc/xfree in cpufreq_del_cpu assert for >> this. > > Can't you just kill_timer()? Adding extra code into a stop_machine > context is dangerous: e.g., > xmalloc()->alloc_xenheap_pages()->memguard_unguard_range()->map_pages_to_xen > ()->flush_area_all() results in deadlock as other cpus are spinning > with irqs disabled. You are right. kill_timer stop timer and wait until timer handler end if this timer is current running. I can switch to it. BTW, I may need to re-init the killed timer before set_timer on it, right? > >> Change access to cpufreq_statistic_lock from spin_lock to >> spin_lock_irqsave to avoid statistic data access racing between >> cpufreq_statistic_exit and dbs timer handler. > > DBS timer handler is called in softirq context; > cpu_freq_statistic_exit() appears also always to be called from > non-irq context. I don't see what interrupt context you are > protecting against. Ok. It is my mis-unstanding. I used to think do_softirq is also called before irq returns. I will rework another very simple patch soon. Jimmy _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |