)]}'
{
  "commit": "db2c4c7791cd04512093d05afc693c3511a65fd7",
  "tree": "11ad51f5ec2010e32edde2dea5696f90822435f4",
  "parents": [
    "65f2ed2b2fa6034ef9890b60c8fd39fbe76b9d37"
  ],
  "author": {
    "name": "Frederic Weisbecker",
    "email": "fweisbec@gmail.com",
    "time": "Tue Feb 02 23:34:40 2010 +0100"
  },
  "committer": {
    "name": "Frederic Weisbecker",
    "email": "fweisbec@gmail.com",
    "time": "Wed Mar 10 14:26:07 2010 +0100"
  },
  "message": "lockdep: Move lock events under lockdep recursion protection\n\nThere are rcu locked read side areas in the path where we submit\na trace event. And these rcu_read_(un)lock() trigger lock events,\nwhich create recursive events.\n\nOne pair in do_perf_sw_event:\n\n__lock_acquire\n      |\n      |--96.11%-- lock_acquire\n      |          |\n      |          |--27.21%-- do_perf_sw_event\n      |          |          perf_tp_event\n      |          |          |\n      |          |          |--49.62%-- ftrace_profile_lock_release\n      |          |          |          lock_release\n      |          |          |          |\n      |          |          |          |--33.85%-- _raw_spin_unlock\n\nAnother pair in perf_output_begin/end:\n\n__lock_acquire\n      |--23.40%-- perf_output_begin\n      |          |          __perf_event_overflow\n      |          |          perf_swevent_overflow\n      |          |          perf_swevent_add\n      |          |          perf_swevent_ctx_event\n      |          |          do_perf_sw_event\n      |          |          perf_tp_event\n      |          |          |\n      |          |          |--55.37%-- ftrace_profile_lock_acquire\n      |          |          |          lock_acquire\n      |          |          |          |\n      |          |          |          |--37.31%-- _raw_spin_lock\n\nThe problem is not that much the trace recursion itself, as we have a\nrecursion protection already (though it\u0027s always wasteful to recurse).\nBut the trace events are outside the lockdep recursion protection, then\neach lockdep event triggers a lock trace, which will trigger two\nother lockdep events. Here the recursive lock trace event won\u0027t\nbe taken because of the trace recursion, so the recursion stops there\nbut lockdep will still analyse these new events:\n\nTo sum up, for each lockdep events we have:\n\n\tlock_*()\n\t     |\n             trace lock_acquire\n                  |\n                  ----- rcu_read_lock()\n                  |          |\n                  |          lock_acquire()\n                  |          |\n                  |          trace_lock_acquire() (stopped)\n                  |          |\n\t\t  |          lockdep analyze\n                  |\n                  ----- rcu_read_unlock()\n                             |\n                             lock_release\n                             |\n                             trace_lock_release() (stopped)\n                             |\n                             lockdep analyze\n\nAnd you can repeat the above two times as we have two rcu read side\nsections when we submit an event.\n\nThis is fixed in this patch by moving the lock trace event under\nthe lockdep recursion protection.\n\nSigned-off-by: Frederic Weisbecker \u003cfweisbec@gmail.com\u003e\nCc: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nCc: Arnaldo Carvalho de Melo \u003cacme@redhat.com\u003e\nCc: Steven Rostedt \u003crostedt@goodmis.org\u003e\nCc: Paul Mackerras \u003cpaulus@samba.org\u003e\nCc: Hitoshi Mitake \u003cmitake@dcl.info.waseda.ac.jp\u003e\nCc: Li Zefan \u003clizf@cn.fujitsu.com\u003e\nCc: Lai Jiangshan \u003claijs@cn.fujitsu.com\u003e\nCc: Masami Hiramatsu \u003cmhiramat@redhat.com\u003e\nCc: Jens Axboe \u003cjens.axboe@oracle.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "0c30d0455de12e02bad459a1da7cd0641ef4d76e",
      "old_mode": 33188,
      "old_path": "kernel/lockdep.c",
      "new_id": "65b5f5b7c298193f187baa6e10dc32df6fc501b8",
      "new_mode": 33188,
      "new_path": "kernel/lockdep.c"
    }
  ]
}