live-patching.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: madvenka@linux.microsoft.com
Cc: mark.rutland@arm.com, jpoimboe@redhat.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
Subject: Re: [RFC PATCH v2 1/4] arm64: Implement infrastructure for stack trace reliability checks
Date: Thu, 8 Apr 2021 18:17:15 +0100	[thread overview]
Message-ID: <20210408171715.GQ4516@sirena.org.uk> (raw)
In-Reply-To: <20210405204313.21346-2-madvenka@linux.microsoft.com>

[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]

On Mon, Apr 05, 2021 at 03:43:10PM -0500, madvenka@linux.microsoft.com wrote:

> These checks will involve checking the return PC to see if it falls inside
> any special functions where the stack trace is considered unreliable.
> Implement the infrastructure needed for this.

Following up again based on an off-list discussion with Mark Rutland:
while I think this is a reasonable implementation for specifically
listing functions that cause problems we could make life easier for
ourselves by instead using annotations at the call sites to put things
into sections which indicate that they're unsafe for unwinding, we can
then check for any address in one of those sections (or possibly do the
reverse and check for any address in a section we specifically know is
safe) rather than having to enumerate problematic functions in the
unwinder.  This also has the advantage of not having a list that's
separate to the functions themselves so it's less likely that the
unwinder will get out of sync with the rest of the code as things evolve.

We already have SYM_CODE_START() annotations in the code for assembly
functions that aren't using the standard calling convention which should
help a lot here, we could add a variant of that for things that we know
are safe on stacks (like those we expect to find at the bottom of
stacks).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2021-04-08 17:17 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 [this message]
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
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=20210408171715.GQ4516@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=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).