Peter Williams wrote:
In the function wake_up_new_task() a line has been added setting the task's cpu to "this_cpu" but the run queue for the other cpu is passed as the argument to __activate_task() which means that the task will end up being on the run queue for a cpu different to the one to which it has been assigned. The simple fix of changing "rq" to "this_rq" in the call to __activate_task() won't be safe as this_rq isn't locked at this stage.
The simplest fix is to retract the set_task_cpu(p, this_cpu) statement.
Can I take it from the lack of response that you don't acknowledge the existence of this bug?
No. All it means that we haven't been able to get to this yet.
The CPU controller is going through a change of hands (Hubertus is no longer working on it and I'm still coming up to speed on it since I have to finish an I/O controller version first).
It is in fact a serious bug and will result in such undesirable problems as locking the wrong run queue when task_rq_lock() is used.
Thanks for the warning. We'll confirm and rectify this in the next release.
Regards, Shailabh
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
