On Tue, Nov 17, 2015 at 12:21:49PM +0100, Peter Zijlstra wrote: > > Looks that way, I'm not sure we always hold pi_lock there. But I'm low > on sleep, so I could have overlooked something. > > See for example move_queued_task(), we call set_task_cpu() with rq->lock > held, but no pi_lock.
Indeed. > > > I thought the comment above migrate_task_rq_fair() is correct rather > > than CONFIG_LOCKDEP comment in set_task_cpu(), when I read it. I think > > these two comments are conflict each other a little bit, so one of > > those should be fixed. > > Agreed. Which one do you think to be fixed? The one above migrate_task_rq_fair()? I wonder if it would be ok even it does not hold pi_lock in migrate_task_rq_fair(). If you say *no problem*, I will try to fix the comment. > > I meant, if you call __set_task_cpu() before > sched_class::migrate_task_rq(), in that case task_rq_lock() will no > longer fully serialize against set_task_cpu(). > > Because once you've called __set_task_cpu(), task_rq_lock() will acquire > the _other_ rq->lock. And we cannot rely on our rq->lock to serialize > things. I agree with you if migtrate_task_rq() can be serialized by rq->lock without holding pi_lock. (even though I am still wondering..) But I thought it was no problem if migrate_task_rq() was serialized only by pi_lock as the comment above the migrate_task_rq() describes, because breaking rq->lock does not affect the sericalization by pi_lock. I would appreciate it if you would answer my questions. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/