Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Mark Brown <broonie@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: stacktrace: Clarify documentation of EL0 entry frame skipping
Date: Wed,  7 Oct 2020 18:11:38 +0100	[thread overview]
Message-ID: <20201007171138.36015-1-broonie@kernel.org> (raw)

The unwinder suppresses reporting of frames created on entry from EL0 where
both FP and PC are NULL in order to avoid having the final NULL PC
cluttering traces and potentially creating confusion. There is a comment
explaining this which doesn't explicitly call out the case where we have
a valid PC but NULL FP, do so in order to ensure that things are as
clear as possible to readers unfamiliar with the code.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/kernel/stacktrace.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index fa56af1a59c3..0c474d81d4e9 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -107,8 +107,9 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
 	/*
 	 * Frames created upon entry from EL0 have NULL FP and PC values, so
 	 * don't bother reporting these. Frames created by __noreturn functions
-	 * might have a valid FP even if PC is bogus, so only terminate where
-	 * both are NULL.
+	 * might have a valid FP even if PC is bogus and the last frame in a
+	 * normal stack will have a valid PC but NULL FP, so only terminate
+	 * early where both are NULL.
 	 */
 	if (!frame->fp && !frame->pc)
 		return -EINVAL;
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2020-10-07 17:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-07 17:11 Mark Brown [this message]
2020-10-08 10:15 ` [PATCH] arm64: stacktrace: Clarify documentation of EL0 entry frame skipping Mark Rutland
2020-10-08 11:14   ` 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=20201007171138.36015-1-broonie@kernel.org \
    --to=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --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