)]}'
{
  "commit": "0e2a70f87be95b9f2dde3ed84797c64939bee4b0",
  "tree": "937e5a48014cd99a4442dcc87c9a70f231016ff6",
  "parents": [
    "7c53f6b671f4aba70ff15e1b05148b10d58c2837"
  ],
  "author": {
    "name": "Mark Rutland",
    "email": "mark.rutland@arm.com",
    "time": "Fri Oct 23 16:35:27 2020 +0100"
  },
  "committer": {
    "name": "Mark Brown",
    "email": "broonie@kernel.org",
    "time": "Wed Jan 13 16:52:48 2021 +0000"
  },
  "message": "Documentation: livepatch: document reliable stacktrace\n\nAdd documentation for reliable stacktrace. This is intended to describe\nthe semantics and to be an aid for implementing architecture support for\nHAVE_RELIABLE_STACKTRACE.\n\nUnwinding is a subtle area, and architectures vary greatly in both\nimplementation and the set of concerns that affect them, so I\u0027ve tried\nto avoid making this too specific to any given architecture. I\u0027ve used\nexamples from both x86_64 and arm64 to explain corner cases in more\ndetail, but I\u0027ve tried to keep the descriptions sufficient for those who\nare unfamiliar with the particular architecture.\n\nI\u0027ve tried to give rationale for all the recommendations/requirements,\nsince that makes it easier to spot nearby issues, or when a check\nhappens to catch a few things at once. I believe what I have written is\nsound, but as some of this was reverse-engineered I may have missed\nthings worth noting.\n\nI\u0027ve made a few assumptions about preferred behaviour, notably:\n\n* If you can reliably unwind through exceptions, you should (as x86_64\n  does).\n\n* It\u0027s fine to omit ftrace_return_to_handler and other return\n  trampolines so long as these are not subject to patching and the\n  original return address is reported. Most architectures do this for\n  ftrace_return_handler, but not other return trampolines.\n\n* For cases where link register unreliability could result in duplicate\n  entries in the trace or an inverted trace, I\u0027ve assumed this should be\n  treated as unreliable. This specific case shouldn\u0027t matter to\n  livepatching, but I assume that that we want a reliable trace to have\n  the correct order.\n\nSigned-off-by: Mark Rutland \u003cmark.rutland@arm.com\u003e\nCc: Jiri Kosina \u003cjikos@kernel.org\u003e\nCc: Joe Lawrence \u003cjoe.lawrence@redhat.com\u003e\nCc: Jonathan Corbet \u003ccorbet@lwn.net\u003e\nCc: Josh Poimboeuf \u003cjpoimboe@redhat.com\u003e\nCc: Mark Brown \u003cbroonie@kernel.org\u003e\nCc: Miroslav Benes \u003cmbenes@suse.cz\u003e\nCc: Petr Mladek \u003cpmladek@suse.com\u003e\nCc: linux-doc@vgert.kernel.org\nCc: live-patching@vger.kernel.org\n[Updates following review -- broonie]\nSigned-off-by: Mark Brown \u003cbroonie@kernel.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "525944063be7aac9f4b20766830fefe6ff9d5796",
      "old_mode": 33188,
      "old_path": "Documentation/livepatch/index.rst",
      "new_id": "43cce5fad705f58b956b0e39145b64f6f3901581",
      "new_mode": 33188,
      "new_path": "Documentation/livepatch/index.rst"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "a72f26344544d649f2a213377c3bceb87fdb1405",
      "new_mode": 33188,
      "new_path": "Documentation/livepatch/reliable-stacktrace.rst"
    }
  ]
}