)]}'
{
  "commit": "67f8ecc550b5bda03335f845dc869b8501d25fd0",
  "tree": "05c6225f315323f17dd4051e61999a2a65adbfea",
  "parents": [
    "dcc4c2f61cdc7e0ab61b25b8d28205302497a8c4"
  ],
  "author": {
    "name": "Roderick Colenbrander",
    "email": "roderick.colenbrander@sony.com",
    "time": "Wed May 18 13:11:09 2016 -0700"
  },
  "committer": {
    "name": "Jiri Kosina",
    "email": "jkosina@suse.cz",
    "time": "Wed Jun 01 16:24:54 2016 +0200"
  },
  "message": "HID: uhid: fix timeout when probe races with IO\n\nMany devices use userspace bluetooth stacks like BlueZ or Bluedroid in combination\nwith uhid. If any of these stacks is used with a HID device for which the driver\nperforms a HID request as part .probe (or technically another HID operation),\nthis results in a deadlock situation. The deadlock results in a 5 second timeout\nfor I/O operations in HID drivers, so isn\u0027t fatal, but none of the I/O operations\nhave a chance of succeeding.\n\nThe root cause for the problem is that uhid only allows for one request to be\nprocessed at a time per uhid instance and locks out other operations. This means\nthat if a user space is creating a new HID device through \u0027UHID_CREATE\u0027, which\nultimately triggers \u0027.probe\u0027 through the HID layer. Then any HID request e.g. a\nread for calibration data would trigger a HID operation on uhid again, but it\nwon\u0027t go out to userspace, because it is still stuck in UHID_CREATE.\nIn addition bluetooth stacks are typically single threaded, so they wouldn\u0027t be\nable to handle any requests while waiting on uhid.\n\nLucikly the UHID spec is somewhat flexible and allows for fixing the issue,\nwithout breaking user space. The idea which the patch implements as discussed\nwith David Herrmann is to decouple adding of a hid device (which triggers .probe)\nfrom UHID_CREATE. The work will kick off roughly once UHID_CREATE completed (or\nelse will wait a tiny bit of time in .probe for a lock). A HID driver has to call\nHID to call \u0027hid_hw_start()\u0027 as part of .probe once it is ready for I/O, which\ntriggers UHID_START to user space. Any HID operations should function now within\n.probe and won\u0027t deadlock because userspace is stuck on UHID_CREATE.\n\nWe verified this patch on Bluedroid with Android 6.0 and on desktop Linux with\nBlueZ stacks. Prior to the patch they had the deadlock issue.\n\n[jkosina@suse.cz: reword subject]\nSigned-off-by: Roderick Colenbrander \u003croderick.colenbrander@sony.com\u003e\nCc: stable@vger.kernel.org\nSigned-off-by: Jiri Kosina \u003cjkosina@suse.cz\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "16b6f11a07001c7831a987e6bd891b7d00868f65",
      "old_mode": 33188,
      "old_path": "drivers/hid/uhid.c",
      "new_id": "99ec3ff7563b3e75ce0c050ba7d28064d445c7af",
      "new_mode": 33188,
      "new_path": "drivers/hid/uhid.c"
    }
  ]
}