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
|
Home