)]}'
{
  "commit": "88db5e1489f23876a226f5393fd978ddc09dc5f9",
  "tree": "69e7d810ce0e575df1f4f9fa860bcd6f155591e6",
  "parents": [
    "262a7a28de060f3a63cae20035876d6f22fd7670"
  ],
  "author": {
    "name": "Alexey Starikovskiy",
    "email": "alexey.y.starikovskiy@intel.com",
    "time": "Wed May 09 23:31:03 2007 -0400"
  },
  "committer": {
    "name": "Len Brown",
    "email": "len.brown@intel.com",
    "time": "Wed May 09 23:31:03 2007 -0400"
  },
  "message": "ACPI: created a dedicated workqueue for notify() execution\n\nHP nx6125/nx6325/... machines have a _GPE handler with an infinite\nloop sending Notify() events to different ACPI subsystems.\n\nNotify handler in ACPI driver is a C-routine, which may call ACPI\ninterpreter again to get access to some ACPI variables\n(acpi_evaluate_xxx).\nOn these HP machines such an evaluation changes state of some variable\nand lets the loop above break.\n\nIn the current ACPI implementation Notify requests are being deferred\nto the same kacpid workqueue on which the above GPE handler with\ninfinite loop is executing. Thus we have a deadlock -- loop will\ncontinue to spin, sending notify events, and at the same time\npreventing these notify events from being run on a workqueue. All\nnotify events are deferred, thus we see increase in memory consumption\nnoticed by author of the thread. Also as GPE handling is bloked,\nmachines overheat. Eventually by external poll of the same\nacpi_evaluate, kacpid is released and all the queued notify events are\nfree to run, thus 100% cpu utilization by kacpid for several seconds\nor more.\n\nTo prevent all these horrors it\u0027s needed to not put notify events to\nkacpid workqueue by either executing them immediately or putting them\non some other thread. It\u0027s dangerous to execute notify events in\nplace, as it will put several ACPI interpreter stacks on top of each\nother (at least 4 in case of nx6125), thus causing kernel  stack\noverflow.\n\nFirst attempt to create a new thread was done by Peter Wainwright\nHe created a bunch of threads, which were stealing work from a kacpid\nworkqueue.\nThis patch appeared in 2.6.15 kernel shipped with Ubuntu 6.06 LTS.\n\nSecond attempt was done by me, I created a new thread for each Notify\nevent. This worked OK on HP nx machines, but broke Linus\u0027 Compaq\nn620c, by producing threads with a speed what they stopped the machine\ncompletely. Thus this patch was reverted from 18-rc2 as I remember.\nI re-made the patch to create second workqueue just for notify events,\nthus hopping it will not break Linus\u0027 machine. Patch was tested on the\nsame HP nx machines in #5534 and #7122, but I did not received reply\nfrom Linus on a test patch sent to him.\nPatch went to 19-rc and was rejected with much fanfare again.\nThere was 4th patch, which inserted schedule_timeout(1) into deferred\nexecution of kacpid, if we had any notify requests pending, but Linus\ndecided that it was too complex (involved either changes to workqueue\nto see if it\u0027s empty or atomic inc/dec).\nNow you see last variant which adds yield() to every GPE execution.\n\nhttp://bugzilla.kernel.org/show_bug.cgi?id\u003d5534\nhttp://bugzilla.kernel.org/show_bug.cgi?id\u003d8385\n\nSigned-off-by: Alexey Starikovskiy \u003calexey.y.starikovskiy@intel.com\u003e\nSigned-off-by: Len Brown \u003clen.brown@intel.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "c2bed56915e1eafe1559d906ba06661764990d45",
      "old_mode": 33188,
      "old_path": "drivers/acpi/osl.c",
      "new_id": "b998340e23d4126074a36cc1af38d05461b4bde9",
      "new_mode": 33188,
      "new_path": "drivers/acpi/osl.c"
    }
  ]
}