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

[David Vrabel <david.vrabel@citrix.com>]

On 11/10/13 10:32, Jan Beulich wrote:
>>>> On 11.10.13 at 11:02, Andrew Cooper <andrew.cooper3@citrix.com> 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?

David