From: Mark Rutland <mark.rutland@arm.com> To: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org> Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Chen Jun <chenjun102@huawei.com>, Marco Elver <elver@google.com>, Mark Brown <broonie@kernel.org> Subject: Re: [PATCH] arm64: stacktrace: don't trace arch_stack_walk() Date: Mon, 22 Mar 2021 13:01:58 +0000 [thread overview] Message-ID: <20210322130158.GA78652@C02TD0UTHF1T.local> (raw) In-Reply-To: <20210319190205.GI6832@arm.com> On Fri, Mar 19, 2021 at 07:02:06PM +0000, Catalin Marinas wrote: > On Fri, Mar 19, 2021 at 06:41:06PM +0000, Mark Rutland wrote: > > We recently converted arm64 to use arch_stack_walk() in commit: > > > > 5fc57df2f6fd ("arm64: stacktrace: Convert to ARCH_STACKWALK") > > > > The core stacktrace code expects that (when tracing the current task) > > arch_stack_walk() starts a trace at its caller, and does not include > > itself in the trace. However, arm64's arch_stack_walk() includes itself, > > and so traces include one more entry than callers expect. The core > > stacktrace code which calls arch_stack_walk() tries to skip a number of > > entries to prevent itself appearing in a trace, and the additional entry > > prevents skipping one of the core stacktrace functions, leaving this in > > the trace unexpectedly. > > > > We can fix this by having arm64's arch_stack_walk() begin the trace with > > its caller. The first value returned by the trace will be > > __builtin_return_address(0), i.e. the caller of arch_stack_walk(). The > > first frame record to be unwound will be __builtin_frame_address(1), > > i.e. the caller's frame record. To prevent surprises, arch_stack_walk() > > is also marked noinline. [...] > > Fixes: 5fc57df2f6fd ("arm64: stacktrace: Convert to ARCH_STACKWALK") > > Signed-off-by: Mark Rutland <mark.rutland@arm.com> > > Cc: Catalin Marinas <catalin.marinas@arm.com> > > Cc: Chen Jun <chenjun102@huawei.com> > > Cc: Marco Elver <elver@google.com> > > Cc: Mark Brown <broonie@kernel.org> > > Cc: Will Deacon <will@kernel.org> > > Thanks Mark. I think we should add a cc stable, just with Fixes doesn't > always seem to end up in a stable kernel: > > Cc: <stable@vger.kernel.org> # 5.10.x Makes sense to me, sure. > With that: > > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Thanks! Will, I assume you're happy to fold in the above when picking this. If you'd prefer I repost with that folded in, please let me know! Mark.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com> To: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org> Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Chen Jun <chenjun102@huawei.com>, Marco Elver <elver@google.com>, Mark Brown <broonie@kernel.org> Subject: Re: [PATCH] arm64: stacktrace: don't trace arch_stack_walk() Date: Mon, 22 Mar 2021 13:01:58 +0000 [thread overview] Message-ID: <20210322130158.GA78652@C02TD0UTHF1T.local> (raw) In-Reply-To: <20210319190205.GI6832@arm.com> On Fri, Mar 19, 2021 at 07:02:06PM +0000, Catalin Marinas wrote: > On Fri, Mar 19, 2021 at 06:41:06PM +0000, Mark Rutland wrote: > > We recently converted arm64 to use arch_stack_walk() in commit: > > > > 5fc57df2f6fd ("arm64: stacktrace: Convert to ARCH_STACKWALK") > > > > The core stacktrace code expects that (when tracing the current task) > > arch_stack_walk() starts a trace at its caller, and does not include > > itself in the trace. However, arm64's arch_stack_walk() includes itself, > > and so traces include one more entry than callers expect. The core > > stacktrace code which calls arch_stack_walk() tries to skip a number of > > entries to prevent itself appearing in a trace, and the additional entry > > prevents skipping one of the core stacktrace functions, leaving this in > > the trace unexpectedly. > > > > We can fix this by having arm64's arch_stack_walk() begin the trace with > > its caller. The first value returned by the trace will be > > __builtin_return_address(0), i.e. the caller of arch_stack_walk(). The > > first frame record to be unwound will be __builtin_frame_address(1), > > i.e. the caller's frame record. To prevent surprises, arch_stack_walk() > > is also marked noinline. [...] > > Fixes: 5fc57df2f6fd ("arm64: stacktrace: Convert to ARCH_STACKWALK") > > Signed-off-by: Mark Rutland <mark.rutland@arm.com> > > Cc: Catalin Marinas <catalin.marinas@arm.com> > > Cc: Chen Jun <chenjun102@huawei.com> > > Cc: Marco Elver <elver@google.com> > > Cc: Mark Brown <broonie@kernel.org> > > Cc: Will Deacon <will@kernel.org> > > Thanks Mark. I think we should add a cc stable, just with Fixes doesn't > always seem to end up in a stable kernel: > > Cc: <stable@vger.kernel.org> # 5.10.x Makes sense to me, sure. > With that: > > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Thanks! Will, I assume you're happy to fold in the above when picking this. If you'd prefer I repost with that folded in, please let me know! Mark. _______________________________________________ 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-03-22 13:16 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-19 18:41 [PATCH] arm64: stacktrace: don't trace arch_stack_walk() Mark Rutland 2021-03-19 18:41 ` Mark Rutland 2021-03-19 19:02 ` Catalin Marinas 2021-03-19 19:02 ` Catalin Marinas 2021-03-22 13:01 ` Mark Rutland [this message] 2021-03-22 13:01 ` Mark Rutland 2021-03-22 12:13 ` Mark Brown 2021-03-22 12:13 ` Mark Brown 2021-03-22 13:19 ` Will Deacon 2021-03-22 13:19 ` Will Deacon 2021-03-22 15:57 ` Ard Biesheuvel 2021-03-22 15:57 ` Ard Biesheuvel 2021-03-22 16:05 ` Ard Biesheuvel 2021-03-22 16:05 ` Ard Biesheuvel
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=20210322130158.GA78652@C02TD0UTHF1T.local \ --to=mark.rutland@arm.com \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=chenjun102@huawei.com \ --cc=elver@google.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --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.