From: Mark Brown <broonie@kernel.org>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>,
Mark Rutland <mark.rutland@arm.com>,
jthierry@redhat.com, catalin.marinas@arm.com, will@kernel.org,
linux-arm-kernel@lists.infradead.org,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
Date: Mon, 12 Apr 2021 17:59:33 +0100 [thread overview]
Message-ID: <20210412165933.GD5379@sirena.org.uk> (raw)
In-Reply-To: <20210409223227.rvf6tfhvgnpzmabn@treble>
[-- Attachment #1.1: Type: text/plain, Size: 1061 bytes --]
On Fri, Apr 09, 2021 at 05:32:27PM -0500, Josh Poimboeuf wrote:
> Hm, for that matter, even without renaming things, a comment above
> stack_trace_save_tsk_reliable() describing the meaning of "reliable"
> would be a good idea.
Might be better to place something at the prototype for
arch_stack_walk_reliable() or cross link the two since that's where any
new architectures should be starting, or perhaps even better to extend
the document that Mark wrote further and point to that from both places.
Some more explict pointer to live patching as the only user would
definitely be good but I think the more important thing would be writing
down any assumptions in the API that aren't already written down and
we're supposed to be relying on. Mark's document captured a lot of it
but it sounds like there's more here, and even with knowing that this
interface is only used by live patch and digging into what it does it's
not always clear what happens to work with the code right now and what's
something that's suitable to be relied on.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-04-12 17:01 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
2021-04-05 20:43 ` [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks madvenka
2021-04-05 20:43 ` [RFC PATCH v2 1/4] arm64: Implement infrastructure for " madvenka
2021-04-08 15:15 ` Mark Brown
2021-04-08 17:17 ` Mark Brown
2021-04-08 19:30 ` Madhavan T. Venkataraman
2021-04-08 23:30 ` Madhavan T. Venkataraman
2021-04-09 11:57 ` Mark Brown
2021-04-05 20:43 ` [RFC PATCH v2 2/4] arm64: Mark a stack trace unreliable if an EL1 exception frame is detected madvenka
2021-04-05 20:43 ` [RFC PATCH v2 3/4] arm64: Detect FTRACE cases that make the stack trace unreliable madvenka
2021-04-08 16:58 ` Mark Brown
2021-04-08 19:23 ` Madhavan T. Venkataraman
2021-04-09 11:31 ` Mark Brown
2021-04-09 14:02 ` Madhavan T. Venkataraman
2021-04-09 12:27 ` Mark Rutland
2021-04-09 17:23 ` Madhavan T. Venkataraman
2021-04-05 20:43 ` [RFC PATCH v2 4/4] arm64: Mark stack trace as unreliable if kretprobed functions are present madvenka
2021-04-09 12:09 ` [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks Mark Rutland
2021-04-09 17:16 ` Madhavan T. Venkataraman
2021-04-09 21:37 ` Josh Poimboeuf
2021-04-09 22:05 ` Madhavan T. Venkataraman
2021-04-09 22:32 ` Josh Poimboeuf
2021-04-09 22:53 ` Josh Poimboeuf
2021-04-11 17:54 ` Madhavan T. Venkataraman
2021-04-12 16:59 ` Mark Brown [this message]
2021-04-13 22:53 ` Josh Poimboeuf
2021-04-14 12:24 ` Mark Brown
2021-04-12 17:36 ` Mark Brown
2021-04-12 19:55 ` Madhavan T. Venkataraman
2021-04-13 11:02 ` Mark Brown
2021-04-14 10:23 ` Madhavan T. Venkataraman
2021-04-14 12:35 ` Mark Brown
2021-04-16 14:43 ` Madhavan T. Venkataraman
2021-04-16 15:36 ` Mark Brown
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210412165933.GD5379@sirena.org.uk \
--to=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=jpoimboe@redhat.com \
--cc=jthierry@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=madvenka@linux.microsoft.com \
--cc=mark.rutland@arm.com \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).