On 11/10/18 14:53, Peter Zijlstra wrote: [...] > I think it was the safe and simple choice; note that we're not migrating > just a single @p, but a whole chain of @p. rq->curr must not be any of the > possible @p's. rq->idle, is per definition not one of the @p's. > > Does that make sense? It does, and I guess is most probably the safest choice indeed. But, just to put together a proper comment for next version.. The chain we are migrating is composed of blocked_task(s), so tasks that blocked on a mutex owned by @p. Now, if such a chain has been built, it means that proxy() has been called "for" @p previously, and @p might be curr while one of its waiters might be proxy. So, none of the blocked_ task(s) should be rq->curr (even if one of their scheduling context might be in use)?
