)]}'
{
  "commit": "d0725992c8a6fb63a16bc9e8b2a50094cc4db3cd",
  "tree": "55b52c5bcc051c3b8c2fc3122000925541d5707b",
  "parents": [
    "c82e6d450fda56cb2d4f68534173d3cd11b32f9f"
  ],
  "author": {
    "name": "Thomas Gleixner",
    "email": "tglx@linutronix.de",
    "time": "Thu Jun 11 23:15:43 2009 +0200"
  },
  "committer": {
    "name": "Thomas Gleixner",
    "email": "tglx@linutronix.de",
    "time": "Wed Jun 24 21:27:35 2009 +0200"
  },
  "message": "futex: Fix the write access fault problem for real\n\ncommit 64d1304a64 (futex: setup writeable mapping for futex ops which\nmodify user space data) did address only half of the problem of write\naccess faults.\n\nThe patch was made on two wrong assumptions:\n\n1) access_ok(VERIFY_WRITE,...) would actually check write access.\n\n   On x86 it does _NOT_. It\u0027s a pure address range check.\n\n2) a RW mapped region can not go away under us.\n\n   That\u0027s wrong as well. Nobody can prevent another thread to call\n   mprotect(PROT_READ) on that region where the futex resides. If that\n   call hits between the get_user_pages_fast() verification and the\n   actual write access in the atomic region we are toast again.\n\nThe solution is to not rely on access_ok and get_user() for any write\naccess related fault on private and shared futexes. Instead we need to\nfault it in with verification of write access.\n\nThere is no generic non destructive write mechanism which would fault\nthe user page in trough a #PF, but as we already know that we will\nfault we can as well call get_user_pages() directly and avoid the #PF\noverhead.\n\nIf get_user_pages() returns -EFAULT we know that we can not fix it\nanymore and need to bail out to user space.\n\nRemove a bunch of confusing comments on this issue as well.\n\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: stable@kernel.org\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "80b5ce716596a95b797a00c417b5a514f9d5d2a2",
      "old_mode": 33188,
      "old_path": "kernel/futex.c",
      "new_id": "1c337112335c60d6831d7b5cf1ee9a26cba54a77",
      "new_mode": 33188,
      "new_path": "kernel/futex.c"
    }
  ]
}