)]}'
{
  "commit": "ffb4ba76a25ab6c9deeec33e4f58395586ca747c",
  "tree": "378ee35adc486466c88c7423dbb0ecc6f027ef45",
  "parents": [
    "83097aca8567a0bd593534853b71fe0fa9a75d69"
  ],
  "author": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Mon Aug 25 11:10:26 2008 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Mon Aug 25 11:10:26 2008 -0700"
  },
  "message": "[module] Don\u0027t let gcc inline load_module()\n\n\u0027load_module()\u0027 is a complex function that contains all the ELF section\nlogic, and inlining it is utterly insane.  But gcc will do it, simply\nbecause there is only one call-site.  As a result, all the stack space\nthat is allocated for all the work to load the module will still be\nactive when we actually call the module init sequence, and the deep call\nchain makes stack overflows happen.\n\nAnd stack overflows are really hard to debug, because they not only\ncorrupt random pages below the stack, but also corrupt the thread_info\nstructure that is allocated under the stack.\n\nIn this case, Alan Brunelle reported some crazy oopses at bootup, after\nloading the processor module that ends up doing complex ACPI stuff and\nhas quite a deep callchain.  This should fix it, and is the sane thing\nto do regardless.\n\nCc: Alan D. Brunelle \u003cAlan.Brunelle@hp.com\u003e\nCc: Arjan van de Ven \u003carjan@linux.intel.com\u003e\nCc: Rusty Russell \u003crusty@rustcorp.com.au\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "08864d257eb0ece2239cd86008973826bc49abd0",
      "old_mode": 33188,
      "old_path": "kernel/module.c",
      "new_id": "9db11911e04b7b55df05fd9f928f5629fe46430d",
      "new_mode": 33188,
      "new_path": "kernel/module.c"
    }
  ]
}