linux-arm-kernel.lists.infradead.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, ardb@kernel.org,
	jthierry@redhat.com, catalin.marinas@arm.com, will@kernel.org,
	jmorris@namei.org, pasha.tatashin@soleen.com,
	linux-arm-kernel@lists.infradead.org,
	live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v4 0/2] arm64: Stack trace reliability checks in the unwinder
Date: Fri, 21 May 2021 18:18:08 +0100	[thread overview]
Message-ID: <20210521171808.GC5825@sirena.org.uk> (raw)
In-Reply-To: <20210516040018.128105-1-madvenka@linux.microsoft.com>


[-- Attachment #1.1: Type: text/plain, Size: 2300 bytes --]

On Sat, May 15, 2021 at 11:00:16PM -0500, madvenka@linux.microsoft.com wrote:

> Special cases
> =============
> 
> Some special cases need to be mentioned:

I think it'd be good if more of this cover letter, especially sections
like this which cover the tricky bits, ended up in the code somehow -
it's recorded here and will be in the list archive but that's not the
most discoverable place so increases the maintainance burden.  It'd be
great to be able to compare the code directly with the reliable
stacktrace requirements document and see everything getting ticked off,
actually going all the way there might be too much and loose the code in
the comments but I think we can get closer to it than we are.  Given
that a lot of this stuff rests on the denylist perhaps some comments
just before it's called would be a good place to start?

> 	- EL1 interrupt and exception handlers end up in sym_code_ranges[].
> 	  So, all EL1 interrupt and exception stack traces will be considered
> 	  unreliable. This the correct behavior as interrupts and exceptions

This stuff about exceptions and preemption is a big one, rejecting any
exceptions makes a whole host of things easier (eg, Mark Rutland raised
interactions between non-AAPCS code and PLTs as being an issue but if
we're able to reliably reject stacks featuring any kind of preemption
anyway that should sidestep the issue).

> Performance
> ===========

> Currently, unwinder_blacklisted() does a linear search through
> sym_code_functions[]. If reviewers prefer, I could sort the
> sym_code_functions[] array and perform a binary search for better
> performance. There are about 80 entries in the array.

If people are trying to live patch a very busy/big system then this
could be an issue, equally there's probably more people focused on
getting boot times as fast as possible than live patching.  Deferring
the initialisation to first use would help boot times with or without
sorting, without numbers I don't actually know that sorting is worth the
effort or needs doing immediately - obvious correctness is also a
benefit!  My instinct is that for now it's probably OK leaving it as a
linear scan and then revisiting if it's not adequately performant, but
I'd defer to actual users there.

[-- 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

  parent reply	other threads:[~2021-05-21 17:19 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <68eeda61b3e9579d65698a884b26c8632025e503>
2021-05-16  4:00 ` madvenka
2021-05-16  4:00   ` [RFC PATCH v4 1/2] arm64: Introduce stack " madvenka
2021-05-21 16:11     ` Mark Brown
2021-05-21 17:23       ` Madhavan T. Venkataraman
2021-05-21 17:42         ` Mark Brown
2021-05-21 17:47           ` Madhavan T. Venkataraman
2021-05-21 17:53             ` Mark Brown
2021-05-21 18:48               ` Josh Poimboeuf
2021-05-21 18:59                 ` Madhavan T. Venkataraman
2021-05-21 19:11                   ` Josh Poimboeuf
2021-05-21 19:16                     ` Josh Poimboeuf
2021-05-21 19:41                       ` Madhavan T. Venkataraman
2021-05-21 20:08                         ` Josh Poimboeuf
2021-05-25 21:44               ` Madhavan T. Venkataraman
2021-05-16  4:00   ` [RFC PATCH v4 2/2] arm64: Create a list of SYM_CODE functions, blacklist them " madvenka
2021-05-19  2:06     ` nobuta.keiya
2021-05-19  3:38       ` Madhavan T. Venkataraman
2021-05-19 19:27     ` Mark Brown
2021-05-20  2:00       ` Madhavan T. Venkataraman
2021-05-21 17:18   ` Mark Brown [this message]
2021-05-21 17:32     ` [RFC PATCH v4 0/2] arm64: Stack trace reliability checks " Madhavan T. Venkataraman
2021-05-21 17:47       ` Mark Brown
2021-05-21 17:48         ` Madhavan T. Venkataraman

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=20210521171808.GC5825@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=jmorris@namei.org \
    --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=pasha.tatashin@soleen.com \
    --cc=will@kernel.org \
    --subject='Re: [RFC PATCH v4 0/2] arm64: Stack trace reliability checks in the unwinder' \
    /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

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