archive mirror
 help / color / mirror / Atom feed
From: "Madhavan T. Venkataraman" <>
To: Mark Brown <>
Subject: Re: [RFC PATCH v4 0/2] arm64: Stack trace reliability checks in the unwinder
Date: Fri, 21 May 2021 12:32:52 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 5/21/21 12:18 PM, Mark Brown wrote:
> On Sat, May 15, 2021 at 11:00:16PM -0500, 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?

I will add more comments in the code to make it clear.

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

Yes. I will include this in the code comments.

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

I have followed the example in the Kprobe deny list. I place the section
in initdata so it can be unloaded during boot. This means that I need to
copy the information before that in early_initcall().

If the initialization must be performed on first use, I probably have to
move SYM_CODE_FUNCTIONS from initdata to some other place where it will
be retained.

If you prefer this, I could do it this way.



linux-arm-kernel mailing list

  reply	other threads:[~2021-05-21 17:34 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   ` [RFC PATCH v4 0/2] arm64: Stack trace reliability checks " Mark Brown
2021-05-21 17:32     ` Madhavan T. Venkataraman [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [RFC PATCH v4 0/2] arm64: Stack trace reliability checks in the unwinder' \

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