)]}'
{
  "commit": "e579dcbf23604cb33c08b5c3c3ac06ca36e7c683",
  "tree": "293581684fc47260a4610e4a77510b459346e2aa",
  "parents": [
    "6997a6faaa129a1c91775f7344c8d371a05178ea"
  ],
  "author": {
    "name": "john stultz",
    "email": "johnstul@us.ibm.com",
    "time": "Sun Aug 13 23:24:24 2006 -0700"
  },
  "committer": {
    "name": "Greg Kroah-Hartman",
    "email": "gregkh@suse.de",
    "time": "Mon Aug 14 12:54:29 2006 -0700"
  },
  "message": "[PATCH] futex_handle_fault always fails\n\nWe found this issue last week w/ the -RT kernel, but it seems the same\nissue is in mainline as well.\n\nBasically it is possible for futex_unlock_pi to return without actually\nfreeing the lock.  This is due to buggy logic in the use of\nfutex_handle_fault() and its attempt argument in a failure case.\n\nLooking at futex.c the logic is as follows:\n\n1) In futex_unlock_pi() we start w/ ret\u003d0 and we go down to the first\n   futex_atomic_cmpxchg_inatomic(), where we find uval\u003d\u003d-EFAULT.  We then\n   jump to the pi_faulted label.\n\n2) From pi_faulted: We increment attempt, unlock the sem and hit the\n   retry label.\n\n3) From the retry label, with ret still zero, we again hit EFAULT on the\n   first futex_atomic_cmpxchg_inatomic(), and again goto the pi_faulted\n   label.\n\n4) Again from pi_faulted: we increment attempt and enter the\n   conditional, where we call futex_handle_fault.\n\n5) futex_handle_fault fails, and we goto the out_unlock_release_sem\n   label.\n\n6) From out_unlock_release_sem we return, and since ret is still zero,\n   we return without error, while never actually unlocking the lock.\n\nIssue #1: at the first futex_atomic_cmpxchg_inatomic() we should probably\nbe setting ret\u003d-EFAULT before jumping to pi_faulted: However in our case\nthis doesn\u0027t really affect anything, as the glibc we\u0027re using ignores the\nerror value from futex_unlock_pi().\n\nIssue #2: Look at futex_handle_fault(), its first conditional will return\n-EFAULT if attempt is \u003e\u003d 2.  However, from the \"if(attempt++)\nfutex_handle_fault(attempt)\" logic above, we\u0027ll *never* call\nfutex_handle_fault when attempt is less then two.  So we never get a chance\nto even try to fault the page in.\n\nThe following patch addresses these two issues by 1) Always setting ret to\n-EFAULT if futex_handle_fault fails, and 2) Removing the \u003d in\nfutex_handle_fault\u0027s (attempt \u003e\u003d 2) check.\n\nI\u0027m really not sure this is the right fix, but wanted to bring it up so\nfolks knew the issue is alive and well in the current -git tree.  From\nlooking at the git logs the logic was first introduced (then later copied\nto other places) in the following commit almost a year ago:\n\nhttp://www.kernel.org/git/?p\u003dlinux/kernel/git/torvalds/linux-2.6.git;a\u003dcommitdiff;h\u003d4732efbeb997189d9f9b04708dc26bf8613ed721;hp\u003d5b039e681b8c5f30aac9cc04385cc94be45d0823\n\nCc: Rusty Russell \u003crusty@rustcorp.com.au\u003e\nCc: Ingo Molnar \u003cmingo@elte.hu\u003e\nAcked-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@suse.de\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "c2b2e0b83abf520a5a170252e8d56e4659443448",
      "old_mode": 33188,
      "old_path": "kernel/futex.c",
      "new_id": "d4633c588f33e417df960bff848ba5fa26eb78fe",
      "new_mode": 33188,
      "new_path": "kernel/futex.c"
    }
  ]
}