)]}'
{
  "commit": "8f5bc2abfd4240b1f55425a3d36b6e6c391bc148",
  "tree": "6101e64f0d06ef59c2bd4080f227e1a7db38a5ce",
  "parents": [
    "a536b126f211bdf9a0eecce0d403a26900d2106c"
  ],
  "author": {
    "name": "Jiri Slaby",
    "email": "jslaby@suse.cz",
    "time": "Tue Mar 01 17:41:10 2011 +0100"
  },
  "committer": {
    "name": "Dave Jones",
    "email": "davej@redhat.com",
    "time": "Tue Mar 01 18:49:44 2011 -0500"
  },
  "message": "[CPUFREQ] fix BUG on cpufreq policy init failure\n\ncpufreq_register_driver sets cpufreq_driver to a structure owned (and\nplaced) in the caller\u0027s memory. If cpufreq policy fails in its -\u003einit\nfunction, sysdev_driver_register returns nonzero in\ncpufreq_register_driver. Now, cpufreq_register_driver returns an error\nwithout setting cpufreq_driver back to NULL.\n\nUsually cpufreq policy modules are unloaded because they propagate the\nerror to the module init function and return that.\n\nSo a later access to any member of cpufreq_driver causes bugs like:\nBUG: unable to handle kernel paging request at ffffffffa00270a0\nIP: [\u003cffffffff8145eca3\u003e] cpufreq_cpu_get+0x53/0xe0\nPGD 1805067 PUD 1809063 PMD 1c3f90067 PTE 0\nOops: 0000 [#1] SMP\nlast sysfs file: /sys/devices/virtual/net/tun0/statistics/collisions\nCPU 0\nModules linked in: ...\nPid: 5677, comm: thunderbird-bin Tainted: G        W   2.6.38-rc4-mm1_64+ #1389 To be filled by O.E.M./To Be Filled By O.E.M.\nRIP: 0010:[\u003cffffffff8145eca3\u003e]  [\u003cffffffff8145eca3\u003e] cpufreq_cpu_get+0x53/0xe0\nRSP: 0018:ffff8801aec37d98  EFLAGS: 00010086\nRAX: 0000000000000202 RBX: 0000000000000000 RCX: 0000000000000001\nRDX: ffffffffa00270a0 RSI: 0000000000001000 RDI: ffffffff8199ece8\n...\nCall Trace:\n [\u003cffffffff8145f490\u003e] cpufreq_quick_get+0x10/0x30\n [\u003cffffffff8103f12b\u003e] show_cpuinfo+0x2ab/0x300\n [\u003cffffffff81136292\u003e] seq_read+0xf2/0x3f0\n [\u003cffffffff8126c5d3\u003e] ? __strncpy_from_user+0x33/0x60\n [\u003cffffffff8116850d\u003e] proc_reg_read+0x6d/0xa0\n [\u003cffffffff81116e53\u003e] vfs_read+0xc3/0x180\n [\u003cffffffff81116f5c\u003e] sys_read+0x4c/0x90\n [\u003cffffffff81030dbb\u003e] system_call_fastpath+0x16/0x1b\n...\n\nIt\u0027s all cause by weird fail path handling in cpufreq_register_driver.\nTo fix that, shuffle the code to do proper handling with gotos.\n\nSigned-off-by: Jiri Slaby \u003cjslaby@suse.cz\u003e\nSigned-off-by: Dave Jones \u003cdavej@redhat.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "1109f6848a43940b8e8ed738f891f6560f17f7a8",
      "old_mode": 33188,
      "old_path": "drivers/cpufreq/cpufreq.c",
      "new_id": "5cb4d09919d67f83d99f8bfb837e64c8a660bb46",
      "new_mode": 33188,
      "new_path": "drivers/cpufreq/cpufreq.c"
    }
  ]
}