)]}'
{
  "commit": "b62d32b9166b085a487916eca514b59b5ffdf2b7",
  "tree": "52d8e233c0286ca59d9fd33b5cc328934c6c0710",
  "parents": [
    "e171ce5cc675f30e226b72eb693cee6832bf0a09"
  ],
  "author": {
    "name": "Sarah Sharp",
    "email": "sarah.a.sharp@linux.intel.com",
    "time": "Thu Jun 21 16:28:30 2012 -0700"
  },
  "committer": {
    "name": "Greg Kroah-Hartman",
    "email": "gregkh@linuxfoundation.org",
    "time": "Mon Jul 16 09:04:38 2012 -0700"
  },
  "message": "xhci: Fix hang on back-to-back Set TR Deq Ptr commands.\n\ncommit 0d9f78a92ef5e97d9fe51d9215ebe22f6f0d289d upstream.\n\nThe Microsoft LifeChat 3000 USB headset was causing a very reproducible\nhang whenever it was plugged in.  At first, I thought the host\ncontroller was producing bad transfer events, because the log was filled\nwith errors like:\n\nxhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD\n\nHowever, it turned out to be an xHCI driver bug in the ring expansion\npatches.  The bug is triggered When there are two ring segments, and a\nTD that ends just before a link TRB, like so:\n\n ______________                     _____________\n|              |              ---\u003e | setup TRB B |\n ______________               |     _____________\n|              |              |    |  data TRB B |\n ______________               |     _____________\n| setup TRB A  | \u003c-- deq      |    |  data TRB B |\n ______________               |     _____________\n| data TRB A   |              |    |             | \u003c-- enq, deq\u0027\u0027\n ______________               |     _____________\n| status TRB A |              |    |             |\n ______________               |     _____________\n|  link TRB    |---------------    |  link TRB   |\n _____________  \u003c--- deq\u0027           _____________\n\nTD A (the first control transfer) stalls on the data phase.  That halts\nthe ring.  The xHCI driver moves the hardware dequeue pointer to the\nfirst TRB after the stalled transfer, which happens to be the link TRB.\n\nOnce the Set TR dequeue pointer command completes, the function\nupdate_ring_for_set_deq_completion runs.  That function is supposed to\nupdate the xHCI driver\u0027s dequeue pointer to match the internal hardware\ndequeue pointer.  On the first call this would work fine, and the\nsoftware dequeue pointer would move to deq\u0027.\n\nHowever, if the transfer immediately after that stalled (TD B in this\ncase), another Set TR Dequeue command would be issued.  That would move\nthe hardware dequeue pointer to deq\u0027\u0027.  Once that command completed,\nupdate_ring_for_set_deq_completion would run again.\n\nThe original code would unconditionally increment the software dequeue\npointer, which moved the pointer off the ring segment into la-la-land.\nThe while loop would happy increment the dequeue pointer (possibly\nwrapping it) until it matched the hardware pointer value.\n\nThe while loop would also access all the memory in between the first\nring segment and the second ring segment to determine if it was a link\nTRB.  This could cause general protection faults, although it was\nunlikely because the ring segments came from a DMA pool, and would often\nhave consecutive memory addresses.\n\nIf nothing in that space looked like a link TRB, the deq_seg pointer for\nthe ring would remain on the first segment.  Thus, the deq_seg and the\nsoftware dequeue pointer would get out of sync.\n\nWhen the next transfer event came in after the stalled transfer, the\nxHCI driver code would attempt to convert the software dequeue pointer\ninto a DMA address in order to compare the DMA address for the completed\ntransfer.  Since the deq_seg and the dequeue pointer were out of sync,\nxhci_trb_virt_to_dma would return NULL.\n\nThe transfer event would get ignored, the transfer would eventually\ntimeout, and we would mistakenly convert the finished transfer to no-op\nTRBs.  Some kernel driver (maybe xHCI?) would then get stuck in an\ninfinite loop in interrupt context, and the whole machine would hang.\n\nThis patch should be backported to kernels as old as 3.4, that contain\nthe commit b008df60c6369ba0290fa7daa177375407a12e07 \"xHCI: count free\nTRBs on transfer ring\"\n\nSigned-off-by: Sarah Sharp \u003csarah.a.sharp@linux.intel.com\u003e\nCc: Andiry Xu \u003candiry.xu@amd.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "525a1ee8127a189df44f2bb53d32f3da61a16866",
      "old_mode": 33188,
      "old_path": "drivers/usb/host/xhci-ring.c",
      "new_id": "158175bfecdf143e15ae84b66bc2a3b8eaf0e0a7",
      "new_mode": 33188,
      "new_path": "drivers/usb/host/xhci-ring.c"
    }
  ]
}