)]}'
{
  "commit": "95e0d86badc410d525ea7218fd32df7bfbf9c837",
  "tree": "26764a72a3bc8bfcd2ece90f6faaae928f345066",
  "parents": [
    "0dd52d0df02733dfc2d5f3824e41b96492305384"
  ],
  "author": {
    "name": "Sebastian Andrzej Siewior",
    "email": "sebastian@breakpoint.cc",
    "time": "Thu Sep 24 01:02:55 2009 +0200"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Wed Sep 23 18:12:10 2009 -0700"
  },
  "message": "Revert \"kmod: fix race in usermodehelper code\"\n\nThis reverts commit c02e3f361c7 (\"kmod: fix race in usermodehelper code\")\n\nThe patch is wrong.  UMH_WAIT_EXEC is called with VFORK what ensures\nthat the child finishes prior returing back to the parent.  No race.\n\nIn fact, the patch makes it even worse because it does the thing it\nclaims not do:\n\n - It calls -\u003ecomplete() on UMH_WAIT_EXEC\n\n - the complete() callback may de-allocated subinfo as seen in the\n   following call chain:\n\n    [\u003cc009f904\u003e] (__link_path_walk+0x20/0xeb4) from [\u003cc00a094c\u003e] (path_walk+0x48/0x94)\n    [\u003cc00a094c\u003e] (path_walk+0x48/0x94) from [\u003cc00a0a34\u003e] (do_path_lookup+0x24/0x4c)\n    [\u003cc00a0a34\u003e] (do_path_lookup+0x24/0x4c) from [\u003cc00a158c\u003e] (do_filp_open+0xa4/0x83c)\n    [\u003cc00a158c\u003e] (do_filp_open+0xa4/0x83c) from [\u003cc009ba90\u003e] (open_exec+0x24/0xe0)\n    [\u003cc009ba90\u003e] (open_exec+0x24/0xe0) from [\u003cc009bfa8\u003e] (do_execve+0x7c/0x2e4)\n    [\u003cc009bfa8\u003e] (do_execve+0x7c/0x2e4) from [\u003cc0026a80\u003e] (kernel_execve+0x34/0x80)\n    [\u003cc0026a80\u003e] (kernel_execve+0x34/0x80) from [\u003cc004b514\u003e] (____call_usermodehelper+0x130/0x148)\n    [\u003cc004b514\u003e] (____call_usermodehelper+0x130/0x148) from [\u003cc0024858\u003e] (kernel_thread_exit+0x0/0x8)\n\n   and the path pointer was NULL.  Good that ARM\u0027s kernel_execve()\n   doesn\u0027t check the pointer for NULL or else I wouldn\u0027t notice it.\n\nThe only race there might be is with UMH_NO_WAIT but it is too late for\nme to investigate it now.  UMH_WAIT_PROC could probably also use VFORK\nand we could save one exec.  So the only race I see is with UMH_NO_WAIT\nand recent scheduler changes where the child does not always run first\nmight have trigger here something but as I said, it is late....\n\nSigned-off-by: Sebastian Andrzej Siewior \u003csebastian@breakpoint.cc\u003e\nAcked-by: Neil Horman \u003cnhorman@tuxdriver.com\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "689d20f39305be5d72908dbdf85bdb187051bdcb",
      "old_mode": 33188,
      "old_path": "kernel/kmod.c",
      "new_id": "9fcb53a11f872e958c95bcf37f8558e9bb148d77",
      "new_mode": 33188,
      "new_path": "kernel/kmod.c"
    }
  ]
}