Re: [Xen-devel] [PATCH] sched: fix race between sched_move_domain() and vcpu_wake()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 11.10.13 at 11:36, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
> On 11/10/13 10:32, Jan Beulich wrote:
>>>>> On 11.10.13 at 11:02, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 11/10/2013 09:07, Keir Fraser wrote:
>>>> It feels to me like this is separate from Andrew's concern. Also I think
>>>> that holding the schedule_lock should protect you from changes to
>>>> v->processor. But if that's really unreasonable (e.g., inefficient) then
>>>> your suggestion here is perfectly sensible.
>>>>
>>>> Improving the vcpu_schedule_lock_irq implementations to use the providied
>>>> underlying spin_lock_irq functions would also be nice, I guess :)
>>>
>>> This is an orthogonal issue which could do with fixing.  Do note that
>>> simply making changes to vcpu_schedule_lock() to return the appropriate
>>> lock is not sufficient to fix this issue, as the race with changing
>>> v->processor can cause two cpus to "successfully" lock the vcpu schedule
>>> lock for a particular vcpu.
>> 
>> Yes indeed. It's just that with such adjustments the fix here
>> would become more "natural" in no longer having to open-code
>> the schedule_lock access.
>> 
>> I suppose you scanned the code for other cases like this, and
>> there are none?
> 
> Would it be sensible to get this fix in as-is?  It's a minimal fix that
> I think would be more suitable for backporting to the stable trees
> rather than a reworking of the vcpu_schedule_lock() and friends?

Oh yes, I'm not denying that; it just needs an ack from either
Keir or George. And I'm already working on the follow-on one.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel