From: Petr Mladek <firstname.lastname@example.org>
To: Mark Rutland <email@example.com>
Cc: firstname.lastname@example.org, Jiri Kosina <email@example.com>,
Joe Lawrence <firstname.lastname@example.org>,
Jonathan Corbet <email@example.com>,
Josh Poimboeuf <firstname.lastname@example.org>,
Mark Brown <email@example.com>, Miroslav Benes <firstname.lastname@example.org>,
Subject: Re: [PATCH] Documentation: livepatch: document reliable stacktrace
Date: Tue, 27 Oct 2020 12:16:32 +0100 [thread overview]
Message-ID: <20201027111559.GC31882@alley> (raw)
On Fri 2020-10-23 16:35:27, Mark Rutland wrote:
> Add documentation for reliable stacktrace. This is intended to describe
> the semantics and to be an aid for implementing architecture support for
First, thanks a lot for putting this document together.
I am not expert on stack unwinders and am not sure if some details
should get corrected and added. I believe that it can be done by
others more effectively.
Anyway, the document is well readable and provides a lot of useful
information. I suggest only small change in the style, see below.
> diff --git a/Documentation/livepatch/reliable-stacktrace.rst b/Documentation/livepatch/reliable-stacktrace.rst
> new file mode 100644
> index 0000000000000..d296c93f6f0e0
> --- /dev/null
> +++ b/Documentation/livepatch/reliable-stacktrace.rst
> +2. Requirements
> +Architectures must implement one of the reliable stacktrace functions.
> +Architectures using CONFIG_ARCH_STACKWALK should implement
> +'arch_stack_walk_reliable', and other architectures should implement
> +Principally, the reliable stacktrace function must ensure that either:
> +* The trace includes all functions that the task may be returned to, and the
> + return code is zero to indicate that the trace is reliable.
> +* The return code is non-zero to indicate that the trace is not reliable.
> +.. note::
> + In some cases it is legitimate to omit specific functions from the trace,
> + but all other functions must be reported. These cases are described in
> + futher detail below.
> +Secondly, the reliable stacktrace function should be robust to cases where the
> +stack or other unwind state is corrupt or otherwise unreliable. The function
> +should attempt to detect such cases and return a non-zero error code, and
> +should not get stuck in an infinite loop or access memory in an unsafe way.
> +Specific cases are described in further detail below.
Please, use imperative style when something is required for the
reliability. For example, it means replacing all "should" with "must"
in the above paragraph.
I perfectly understand why you used "should". I use it heavily as
well. But we really must motivate people to handle all corner
cases here. ;-)
next prev parent reply other threads:[~2020-10-27 11:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-23 15:35 [PATCH] Documentation: livepatch: document reliable stacktrace Mark Rutland
2020-10-27 11:16 ` Petr Mladek [this message]
2020-10-29 10:04 ` Miroslav Benes
2021-01-13 16:57 Mark Brown
2021-01-13 19:33 ` Josh Poimboeuf
2021-01-13 20:23 ` Mark Brown
2021-01-13 22:25 ` Josh Poimboeuf
2021-01-14 18:10 ` Mark Rutland
2021-01-15 0:03 ` Josh Poimboeuf
2021-01-14 11:54 ` Mark Rutland
2021-01-14 14:36 ` Josh Poimboeuf
2021-01-14 17:49 ` Mark Rutland
2021-01-14 20:03 ` Josh Poimboeuf
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).