[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


 


Rackspace

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