archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <>
To: Mark Brown <>
Cc:, Mark Rutland <>,
	Jiri Kosina <>,
	Joe Lawrence <>,
	Jonathan Corbet <>, Miroslav Benes <>,,,
	Josh Poimboeuf <>
Subject: Re: [PATCH v4] Documentation: livepatch: document reliable stacktrace
Date: Mon, 18 Jan 2021 15:02:31 +0100	[thread overview]
Message-ID: <YAWU0D50KH4mVTgn@alley> (raw)
In-Reply-To: <>

Hi Mark,

first, thanks a lot for writing this.

On Fri 2021-01-15 17:16:17, Mark Brown wrote:
> From: Mark Rutland <>
> Add documentation for reliable stacktrace. This is intended to describe
> the semantics and to be an aid for implementing architecture support for
> 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.
> I've tried to give rationale for all the recommendations/requirements,
> since that makes it easier to spot nearby issues, or when a check
> happens to catch a few things at once.

The above looks enough for the commit message. Well, Josh, typically
asks for a directive style, example:

Instead of "I've tried to give rationale...", please use something like
"The documentation gives rationale...".

> I believe what I have written is
> sound, but as some of this was reverse-engineered I may have missed
> things worth noting.
> I've made a few assumptions about preferred behaviour, notably:
> * If you can reliably unwind through exceptions, you should (as x86_64
>   does).
> * It's fine to omit ftrace_return_to_handler and other return
>   trampolines so long as these are not subject to patching and the
>   original return address is reported. Most architectures do this for
>   ftrace_return_handler, but not other return trampolines.
> * For cases where link register unreliability could result in duplicate
>   entries in the trace or an inverted trace, I've assumed this should be
>   treated as unreliable. This specific case shouldn't matter to
>   livepatching, but I assume that that we want a reliable trace to have
>   the correct order.

This looks like a background that is typically part of the cover
leter. It mentions some Mark's doubts.

Could anyone please answer whether the above assumptions are correct
or not? We should remove them from the commit message. If any
assumption is wrong, we should fix the documentation.

Honestly, I am curious about the anwer. I am not familiar with
these details of the reliable stacktrace ;-)

Otherwise, it looks good to me on the first look. But I am not
expert in this are, so I could not check the details effectively.

Best Regards,

  reply	other threads:[~2021-01-18 14:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-15 17:16 [PATCH v4] Documentation: livepatch: document reliable stacktrace Mark Brown
2021-01-18 14:02 ` Petr Mladek [this message]
2021-01-18 14:54   ` Josh Poimboeuf
2021-01-18 17:50   ` Mark Rutland

Reply instructions:

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 \
    --in-reply-to=YAWU0D50KH4mVTgn@alley \ \ \ \ \ \ \ \ \ \ \ \

* 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).