)]}'
{
  "commit": "30da688ef6b76e01969b00608202fff1eed2accc",
  "tree": "f4068cb8cf29f1d93d8489b162f41b7ac15a3d0c",
  "parents": [
    "c1804d547dc098363443667609c272d1e4d15ee8"
  ],
  "author": {
    "name": "Oleg Nesterov",
    "email": "oleg@redhat.com",
    "time": "Mon Mar 15 10:10:19 2010 +0100"
  },
  "committer": {
    "name": "Ingo Molnar",
    "email": "mingo@elte.hu",
    "time": "Fri Apr 02 20:12:02 2010 +0200"
  },
  "message": "sched: sched_exec(): Remove the select_fallback_rq() logic\n\nsched_exec()-\u003eselect_task_rq() reads/updates -\u003ecpus_allowed lockless.\nThis can race with other CPUs updating our -\u003ecpus_allowed, and this\nlooks meaningless to me.\n\nThe task is current and running, it must have online cpus in -\u003ecpus_allowed,\nthe fallback mode is bogus. And, if -\u003esched_class returns the \"wrong\" cpu,\nthis likely means we raced with set_cpus_allowed() which was called\nfor reason, why should sched_exec() retry and call -\u003eselect_task_rq()\nagain?\n\nChange the code to call sched_class-\u003eselect_task_rq() directly and do\nnothing if the returned cpu is wrong after re-checking under rq-\u003elock.\n\nFrom now task_struct-\u003ecpus_allowed is always stable under TASK_WAKING,\nselect_fallback_rq() is always called under rq-lock or the caller or\nthe caller owns TASK_WAKING (select_task_rq).\n\nSigned-off-by: Oleg Nesterov \u003coleg@redhat.com\u003e\nSigned-off-by: Peter Zijlstra \u003ca.p.zijlstra@chello.nl\u003e\nLKML-Reference: \u003c20100315091019.GA9141@redhat.com\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "f475c608b073d43de7b101b6f09a48f9487ec146",
      "old_mode": 33188,
      "old_path": "kernel/sched.c",
      "new_id": "165b532dd8c2685b3382c9b7fecf59391cb16264",
      "new_mode": 33188,
      "new_path": "kernel/sched.c"
    }
  ]
}