[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] RE: CPU offlining patch xen-unstable:21049
I think the try_lock is not for the cpu_down(). The point is, if another CPU is trying the get the lock. Considering following scnerio: 1) cpu_down() in CPU A, and get the xenpf_lock, then call to stop_machine_run(), trying to bring all CPU to stop_machine_run context. 2) At the same time, another vcpu in CPU B do a xenpf hypercall, and try to get the xenpf_lock. If ther is no retyr for this lock, it can't get xenpf_lock, it will never go to the softirq So the system will hang. Hope this make thing clear. Thanks --jyh >-----Original Message----- >From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] >Sent: Thursday, April 15, 2010 4:31 PM >To: Jiang, Yunhong >Cc: xen-devel@xxxxxxxxxxxxxxxxxxx >Subject: CPU offlining patch xen-unstable:21049 > >Yunhong, > >Just thinking some more about the above patch, which made the xenpf_lock and >systctl_lock both retryable. I don't think this is necessary after all, >since cpu_down() is called via continue_hypercall_on_cpu(), and hence these >locks are released before the hypercall continuation is executed. Hence we >should be able to revert a couple of hunks of this changeset, as only >cpu_add_remove_lock is actually a problem, wouldn't you agree? > > -- Keir > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |