From: Mark Brown <broonie@kernel.org> To: madvenka@linux.microsoft.com Cc: mark.rutland@arm.com, jpoimboe@redhat.com, ardb@kernel.org, nobuta.keiya@fujitsu.com, catalin.marinas@arm.com, will@kernel.org, jmorris@namei.org, pasha.tatashin@soleen.com, jthierry@redhat.com, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v5 2/2] arm64: Create a list of SYM_CODE functions, check return PC against list Date: Fri, 4 Jun 2021 17:24:15 +0100 [thread overview] Message-ID: <20210604162415.GF4045@sirena.org.uk> (raw) In-Reply-To: <20210526214917.20099-3-madvenka@linux.microsoft.com> [-- Attachment #1: Type: text/plain, Size: 1455 bytes --] On Wed, May 26, 2021 at 04:49:17PM -0500, madvenka@linux.microsoft.com wrote: > The unwinder should check if the return PC falls in any function that > is considered unreliable from an unwinding perspective. If it does, > mark the stack trace unreliable. Reviwed-by: Mark Brown <broonie@kernel.org> However it'd be good for someone else to double check this as it's entirely possible that I've missed some case here. > + * Some special cases covered by sym_code_functions[] deserve a mention here: > + * - All EL1 interrupt and exception stack traces will be considered > + * unreliable. This is the correct behavior as interrupts and exceptions > + * can happen on any instruction including ones in the frame pointer > + * prolog and epilog. Unless stack metadata is available so the unwinder > + * can unwind through these special cases, such stack traces will be > + * considered unreliable. > + * If you're respinning this it's probably also worth noting that we only ever perform reliable stack trace on either blocked tasks or the current task which should if my reasoning is correct mean that the fact that the exclusions here mean that we avoid having to worry about so many race conditions when entering and leaving functions. If we got preempted at the wrong moment for one of them then we should observe the preemption and mark the trace as unreliable due to that which means that any confusion the race causes is a non-issue. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org> To: madvenka@linux.microsoft.com Cc: mark.rutland@arm.com, jpoimboe@redhat.com, ardb@kernel.org, nobuta.keiya@fujitsu.com, catalin.marinas@arm.com, will@kernel.org, jmorris@namei.org, pasha.tatashin@soleen.com, jthierry@redhat.com, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v5 2/2] arm64: Create a list of SYM_CODE functions, check return PC against list Date: Fri, 4 Jun 2021 17:24:15 +0100 [thread overview] Message-ID: <20210604162415.GF4045@sirena.org.uk> (raw) In-Reply-To: <20210526214917.20099-3-madvenka@linux.microsoft.com> [-- Attachment #1.1: Type: text/plain, Size: 1455 bytes --] On Wed, May 26, 2021 at 04:49:17PM -0500, madvenka@linux.microsoft.com wrote: > The unwinder should check if the return PC falls in any function that > is considered unreliable from an unwinding perspective. If it does, > mark the stack trace unreliable. Reviwed-by: Mark Brown <broonie@kernel.org> However it'd be good for someone else to double check this as it's entirely possible that I've missed some case here. > + * Some special cases covered by sym_code_functions[] deserve a mention here: > + * - All EL1 interrupt and exception stack traces will be considered > + * unreliable. This is the correct behavior as interrupts and exceptions > + * can happen on any instruction including ones in the frame pointer > + * prolog and epilog. Unless stack metadata is available so the unwinder > + * can unwind through these special cases, such stack traces will be > + * considered unreliable. > + * If you're respinning this it's probably also worth noting that we only ever perform reliable stack trace on either blocked tasks or the current task which should if my reasoning is correct mean that the fact that the exclusions here mean that we avoid having to worry about so many race conditions when entering and leaving functions. If we got preempted at the wrong moment for one of them then we should observe the preemption and mark the trace as unreliable due to that which means that any confusion the race causes is a non-issue. [-- 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-06-04 16:24 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <ea0ef9ed6eb34618bcf468fbbf8bdba99e15df7d> 2021-05-26 21:49 ` [RFC PATCH v5 0/2] arm64: Implement stack trace reliability checks madvenka 2021-05-26 21:49 ` madvenka 2021-05-26 21:49 ` [RFC PATCH v5 1/2] arm64: Introduce stack trace reliability checks in the unwinder madvenka 2021-05-26 21:49 ` madvenka 2021-06-24 14:40 ` Mark Rutland 2021-06-24 14:40 ` Mark Rutland 2021-06-24 16:03 ` Mark Brown 2021-06-24 16:03 ` Mark Brown 2021-06-25 15:39 ` Madhavan T. Venkataraman 2021-06-25 15:39 ` Madhavan T. Venkataraman 2021-06-25 15:51 ` Mark Brown 2021-06-25 15:51 ` Mark Brown 2021-06-25 17:05 ` Madhavan T. Venkataraman 2021-06-25 17:05 ` Madhavan T. Venkataraman 2021-06-25 17:18 ` Madhavan T. Venkataraman 2021-06-25 17:18 ` Madhavan T. Venkataraman 2021-06-26 15:35 ` Madhavan T. Venkataraman 2021-06-26 15:35 ` Madhavan T. Venkataraman 2021-06-29 16:47 ` Josh Poimboeuf 2021-06-29 16:47 ` Josh Poimboeuf 2021-05-26 21:49 ` [RFC PATCH v5 2/2] arm64: Create a list of SYM_CODE functions, check return PC against list madvenka 2021-05-26 21:49 ` madvenka 2021-06-04 16:24 ` Mark Brown [this message] 2021-06-04 16:24 ` Mark Brown 2021-06-04 20:38 ` Madhavan T. Venkataraman 2021-06-04 20:38 ` Madhavan T. Venkataraman 2021-06-04 16:59 ` Mark Brown 2021-06-04 16:59 ` Mark Brown 2021-06-04 20:40 ` Madhavan T. Venkataraman 2021-06-04 20:40 ` Madhavan T. Venkataraman 2021-06-16 1:52 ` Suraj Jitindar Singh 2021-06-16 1:52 ` Suraj Jitindar Singh 2021-06-16 9:15 ` nobuta.keiya 2021-06-16 9:15 ` nobuta.keiya 2021-06-16 11:10 ` Madhavan T. Venkataraman 2021-06-16 11:10 ` Madhavan T. Venkataraman 2021-06-04 15:29 ` [RFC PATCH v5 0/2] arm64: Implement stack trace reliability checks Mark Brown 2021-06-04 15:29 ` Mark Brown 2021-06-04 20:44 ` Madhavan T. Venkataraman 2021-06-04 20:44 ` 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=20210604162415.GF4045@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=nobuta.keiya@fujitsu.com \ --cc=pasha.tatashin@soleen.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.