From d58c8c5a05a8384d4319a63adde5064f11851fff Mon Sep 17 00:00:00 2001
From: Mark Brown <broonie@kernel.org>
Date: Wed, 20 Jan 2021 16:47:12 +0000
Subject: [PATCH v6 0/2] Documentation: livepatch: Document reliable stacktrace and minor cleanup

This series adds a document, mainly written by Mark Rutland, which makes
explicit the requirements for implementing reliable stacktrace in order
to aid architectures adding this feature.  It also updates the other
livepatching documents to use automatically generated tables of contents
following review comments on Mark's document.

v6:
 - Remove a duplicated "points".
v5:
 - Tweaks to the commit message for the new document.
 - Convert new and existing documents to autogenerated tables of
   contents.
v4:
 - Renumber table of contents
v3:
 - Incorporated objtool section from Mark.
 - Deleted confusing notes about using annotations.

Mark Brown (1):
  Documentation: livepatch: Convert to automatically generated contents

Mark Rutland (1):
  Documentation: livepatch: document reliable stacktrace

 Documentation/livepatch/index.rst             |   1 +
 Documentation/livepatch/livepatch.rst         |  15 +-
 Documentation/livepatch/module-elf-format.rst |  10 +-
 .../livepatch/reliable-stacktrace.rst         | 309 ++++++++++++++++++
 4 files changed, 313 insertions(+), 22 deletions(-)
 create mode 100644 Documentation/livepatch/reliable-stacktrace.rst

base-commit: 7c53f6b671f4aba70ff15e1b05148b10d58c2837
--
2.20.1
Documentation: livepatch: document reliable stacktrace

Add documentation for reliable stacktrace. This is intended to describe
the semantics and to be an aid for implementing architecture support for
HAVE_RELIABLE_STACKTRACE.

Unwinding is a subtle area, and architectures vary greatly in both
implementation and the set of concerns that affect them, so I've tried
to avoid making this too specific to any given architecture. I've used
examples from both x86_64 and arm64 to explain corner cases in more
detail, but I've tried to keep the descriptions sufficient for those who
are unfamiliar with the particular architecture.

This document aims to give rationale for all the recommendations and
requirements, since that makes it easier to spot nearby issues, or when
a check happens to catch a few things at once.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
[Updates following review -- broonie]
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2 files changed