[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] sched: fix race between sched_move_domain() and vcpu_wake()
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? David _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |