From: "Madhavan T. Venkataraman" <firstname.lastname@example.org> To: Mark Brown <email@example.com> Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org 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: <email@example.com> (raw) In-Reply-To: <20210521171808.GC5825@sirena.org.uk> On 5/21/21 12:18 PM, Mark Brown wrote: > On Sat, May 15, 2021 at 11:00:16PM -0500, firstname.lastname@example.org 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. Thanks! Madhavan _______________________________________________ linux-arm-kernel mailing list email@example.com http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent 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: 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --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).