)]}'
{
  "commit": "56839737580d22d5cb2fdc10a683ad55dcfc58a0",
  "tree": "915bc0bf46796da8193fcf933897a2deb4cc99f3",
  "parents": [
    "a882d3560c5490ca260ce456ef1846f28a5896bf"
  ],
  "author": {
    "name": "Vikram Mulukutla",
    "email": "markivx@codeaurora.org",
    "time": "Wed Jun 27 17:25:46 2012 -0700"
  },
  "committer": {
    "name": "Jeremie",
    "email": "jer_l_@live.ca",
    "time": "Sun Jul 15 13:33:56 2012 -0400"
  },
  "message": "panic: Fix a possible deadlock in panic()\n\npanic_lock is meant to ensure that panic processing takes\nplace only on one cpu; if any of the other cpus encounter\na panic, they will spin waiting to be shut down.\n\nHowever, this causes a regression in this scenario:\n\n1. Cpu 0 encounters a panic and acquires the panic_lock\n   and proceeds with the panic processing.\n2. There is an interrupt on cpu 0 that also encounters\n   an error condition and invokes panic.\n3. This second invocation fails to acquire the panic_lock\n   and enters the infinite while loop in panic_smp_self_stop.\n\nThus all panic processing is stopped, and the cpu is stuck\nfor eternity in the while(1) inside panic_smp_self_stop.\n\nTo address this, disable local interrupts with\nlocal_irq_disable before acquiring the panic_lock. This will\nprevent interrupt handlers from executing during the panic\nprocessing, thus avoiding this particular problem.\n\nSigned-off-by: Vikram Mulukutla \u003cmarkivx@codeaurora.org\u003e\n(cherry picked from commit dd58afef43357f265e803c317bbaa91f8c440663)\n\nChange-Id: I5f7ebcf2a028df265a57922b6c959e686a82026a\nSigned-off-by: Swetha Basineni \u003csbasin@codeaurora.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "84595f36cc1f40bb4425a74e647d8df4aa67da34",
      "old_mode": 33188,
      "old_path": "kernel/panic.c",
      "new_id": "c00b0a82c48c0299855b3189637211fb7d1cb16c",
      "new_mode": 33188,
      "new_path": "kernel/panic.c"
    }
  ]
}