From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wei, Gang" Subject: RE: [PATCH]CPUFREQ: Fix two racing issues during cpu hotplug Date: Mon, 12 Apr 2010 14:54:16 +0800 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Monday, 2010-4-12 2:10 PM, Keir Fraser wrote: > On 12/04/2010 05:45, "Wei, Gang" wrote: >=20 >> 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.=20 >=20 > 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 th= is 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? >=20 >> 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. >=20 > 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.=20 Ok. It is my mis-unstanding. I used to think do_softirq is also called befo= re irq returns. I will rework another very simple patch soon. Jimmy=