From: "Björn Töpel" <bjorn@kernel.org> To: "Puranjay Mohan" <puranjay12@gmail.com>, "Paul Walmsley" <paul.walmsley@sifive.com>, "Palmer Dabbelt" <palmer@dabbelt.com>, "Albert Ou" <aou@eecs.berkeley.edu>, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, "Björn Töpel" <bjorn@rivosinc.com> Cc: puranjay12@gmail.com Subject: Re: [PATCH 0/2] riscv: ftrace: make stack walk more robust. Date: Tue, 02 Apr 2024 15:18:48 +0200 [thread overview] Message-ID: <8734s3sy13.fsf@all.your.base.are.belong.to.us> (raw) In-Reply-To: <20240328184020.34278-1-puranjay12@gmail.com> Puranjay Mohan <puranjay12@gmail.com> writes: > The current stack walker in riscv implemented in walk_stackframe() provides > the PC to a callback function when it unwinds the stacks. This doesn't > allow implementing stack walkers that need access to more information like > the frame pointer, etc. > > This series makes walk_stackframe() provide a unwinde_state structure to > callback functions. This structure has all the information that > walk_stackframe() can provide. > > Currently, there are four users of walk_stackframe(): return_address(), > perf_callchain_kernel(), dump_backtrace(), and __get_wchan(). All of these > have been converted to use arch_stack_walk() rather than calling > walk_stackframe() directly. > > We need this to implement arch_bpf_stack_walk() that provides a callback > that needs the FP, SP, and PC. This will be needed for implementing BFP > exceptions for RISCV. Hmm, I wonder if it's easier to have these two patches as part of the BPF exception series, instead of having the dependencies be cross-tree? > There are no functional changes in this series. > > I have tested this by crashing the kernel and looking at the stack trace > with and without CONFIG_FRAME_POINTER I have two really minor style nits, but regardless if they're fixed or not: Reviewed-by: Björn Töpel <bjorn@rivosinc.com>
WARNING: multiple messages have this Message-ID (diff)
From: "Björn Töpel" <bjorn@kernel.org> To: "Puranjay Mohan" <puranjay12@gmail.com>, "Paul Walmsley" <paul.walmsley@sifive.com>, "Palmer Dabbelt" <palmer@dabbelt.com>, "Albert Ou" <aou@eecs.berkeley.edu>, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, "Björn Töpel" <bjorn@rivosinc.com> Cc: puranjay12@gmail.com Subject: Re: [PATCH 0/2] riscv: ftrace: make stack walk more robust. Date: Tue, 02 Apr 2024 15:18:48 +0200 [thread overview] Message-ID: <8734s3sy13.fsf@all.your.base.are.belong.to.us> (raw) In-Reply-To: <20240328184020.34278-1-puranjay12@gmail.com> Puranjay Mohan <puranjay12@gmail.com> writes: > The current stack walker in riscv implemented in walk_stackframe() provides > the PC to a callback function when it unwinds the stacks. This doesn't > allow implementing stack walkers that need access to more information like > the frame pointer, etc. > > This series makes walk_stackframe() provide a unwinde_state structure to > callback functions. This structure has all the information that > walk_stackframe() can provide. > > Currently, there are four users of walk_stackframe(): return_address(), > perf_callchain_kernel(), dump_backtrace(), and __get_wchan(). All of these > have been converted to use arch_stack_walk() rather than calling > walk_stackframe() directly. > > We need this to implement arch_bpf_stack_walk() that provides a callback > that needs the FP, SP, and PC. This will be needed for implementing BFP > exceptions for RISCV. Hmm, I wonder if it's easier to have these two patches as part of the BPF exception series, instead of having the dependencies be cross-tree? > There are no functional changes in this series. > > I have tested this by crashing the kernel and looking at the stack trace > with and without CONFIG_FRAME_POINTER I have two really minor style nits, but regardless if they're fixed or not: Reviewed-by: Björn Töpel <bjorn@rivosinc.com> _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2024-04-02 13:18 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-28 18:40 [PATCH 0/2] riscv: ftrace: make stack walk more robust Puranjay Mohan 2024-03-28 18:40 ` Puranjay Mohan 2024-03-28 18:40 ` [PATCH 1/2] riscv: stacktrace: use arch_stack_walk() in place of walk_stackframe Puranjay Mohan 2024-03-28 18:40 ` Puranjay Mohan 2024-04-02 13:19 ` Björn Töpel 2024-04-02 13:19 ` Björn Töpel 2024-03-28 18:40 ` [PATCH 2/2] riscv: stacktrace: make walk_stackframe() more robust Puranjay Mohan 2024-03-28 18:40 ` Puranjay Mohan 2024-04-02 13:20 ` Björn Töpel 2024-04-02 13:20 ` Björn Töpel 2024-04-02 13:18 ` Björn Töpel [this message] 2024-04-02 13:18 ` [PATCH 0/2] riscv: ftrace: make stack walk " Björn Töpel
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=8734s3sy13.fsf@all.your.base.are.belong.to.us \ --to=bjorn@kernel.org \ --cc=aou@eecs.berkeley.edu \ --cc=bjorn@rivosinc.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=palmer@dabbelt.com \ --cc=paul.walmsley@sifive.com \ --cc=puranjay12@gmail.com \ /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.