[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.