All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	"Naveen N . Rao" <naveen.n.rao@linux.vnet.ibm.com>,
	Ananth N Mavinakayanahalli <ananth@linux.ibm.com>,
	Ingo Molnar <mingo@kernel.org>,
	linux-kernel@vger.kernel.org, Sven Schnelle <svens@linux.ibm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 3/8] arm64: kprobes: Record frame pointer with kretprobe instance
Date: Thu, 14 Oct 2021 22:50:39 +0900	[thread overview]
Message-ID: <20211014225039.b96ff7b7fa86f340ceb50192@kernel.org> (raw)
In-Reply-To: <20211014102702.GB13770@C02TD0UTHF1T.local>

On Thu, 14 Oct 2021 11:27:02 +0100
Mark Rutland <mark.rutland@arm.com> wrote:

> On Thu, Oct 14, 2021 at 07:01:55PM +0900, Masami Hiramatsu wrote:
> > On Thu, 14 Oct 2021 10:13:32 +0100
> > Mark Rutland <mark.rutland@arm.com> wrote:
> > 
> > > On Thu, Oct 14, 2021 at 05:04:05PM +0900, Masami Hiramatsu wrote:
> > > > On Wed, 13 Oct 2021 11:01:39 +0100
> > > > Mark Rutland <mark.rutland@arm.com> wrote:
> > > > 
> > > > > On Fri, Oct 08, 2021 at 09:28:39PM +0900, Masami Hiramatsu wrote:
> > > > > > Record the frame pointer instead of stack address with kretprobe
> > > > > > instance as the identifier on the instance list.
> > > > > > Since arm64 always enable CONFIG_FRAME_POINTER, we can use the
> > > > > > actual frame pointer (x29).
> > > > > 
> > > > > Just to check, why do we need to use the FP rather than SP? It wasn't
> > > > > clear to me if that's necessary later in the series, or if I'm missing
> > > > > something here.
> > > > 
> > > > Actually, this is for finding correct return address from the per-task
> > > > kretprobe instruction list (suppose it as a shadow stack) when it will
> > > > be searched in stack-backtracing. At that point, the framepointer will
> > > > be a reliable key.
> > > 
> > > Sure, my question was more "why isn't the SP a reliable key?", because both
> > > the SP and FP should be balanced at function-entry and function-return
> > > time. I'm asking because I think I'm missing a subtlety.
> > 
> > Ah, because SP is not used while unwinding frame. For the kretprobe,
> > either FP or SP is OK. But for the stacktrace.c, I can not use SP
> > and is easy to change to use FP. :)
> 
> Ah, so this is just so that stacktrace can match the address. For
> clarity, would you be happy to add a sentence to the commit message like:
> 
> | This will allow the stacktrace code to find the original return
> | address from the FP alone.

Yes, I'm happy to update the changelog :)

Thanks!

> 
> Thanks,
> Mark.


-- 
Masami Hiramatsu <mhiramat@kernel.org>

WARNING: multiple messages have this Message-ID (diff)
From: Masami Hiramatsu <mhiramat@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	"Naveen N . Rao" <naveen.n.rao@linux.vnet.ibm.com>,
	Ananth N Mavinakayanahalli <ananth@linux.ibm.com>,
	Ingo Molnar <mingo@kernel.org>,
	linux-kernel@vger.kernel.org, Sven Schnelle <svens@linux.ibm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 3/8] arm64: kprobes: Record frame pointer with kretprobe instance
Date: Thu, 14 Oct 2021 22:50:39 +0900	[thread overview]
Message-ID: <20211014225039.b96ff7b7fa86f340ceb50192@kernel.org> (raw)
In-Reply-To: <20211014102702.GB13770@C02TD0UTHF1T.local>

On Thu, 14 Oct 2021 11:27:02 +0100
Mark Rutland <mark.rutland@arm.com> wrote:

> On Thu, Oct 14, 2021 at 07:01:55PM +0900, Masami Hiramatsu wrote:
> > On Thu, 14 Oct 2021 10:13:32 +0100
> > Mark Rutland <mark.rutland@arm.com> wrote:
> > 
> > > On Thu, Oct 14, 2021 at 05:04:05PM +0900, Masami Hiramatsu wrote:
> > > > On Wed, 13 Oct 2021 11:01:39 +0100
> > > > Mark Rutland <mark.rutland@arm.com> wrote:
> > > > 
> > > > > On Fri, Oct 08, 2021 at 09:28:39PM +0900, Masami Hiramatsu wrote:
> > > > > > Record the frame pointer instead of stack address with kretprobe
> > > > > > instance as the identifier on the instance list.
> > > > > > Since arm64 always enable CONFIG_FRAME_POINTER, we can use the
> > > > > > actual frame pointer (x29).
> > > > > 
> > > > > Just to check, why do we need to use the FP rather than SP? It wasn't
> > > > > clear to me if that's necessary later in the series, or if I'm missing
> > > > > something here.
> > > > 
> > > > Actually, this is for finding correct return address from the per-task
> > > > kretprobe instruction list (suppose it as a shadow stack) when it will
> > > > be searched in stack-backtracing. At that point, the framepointer will
> > > > be a reliable key.
> > > 
> > > Sure, my question was more "why isn't the SP a reliable key?", because both
> > > the SP and FP should be balanced at function-entry and function-return
> > > time. I'm asking because I think I'm missing a subtlety.
> > 
> > Ah, because SP is not used while unwinding frame. For the kretprobe,
> > either FP or SP is OK. But for the stacktrace.c, I can not use SP
> > and is easy to change to use FP. :)
> 
> Ah, so this is just so that stacktrace can match the address. For
> clarity, would you be happy to add a sentence to the commit message like:
> 
> | This will allow the stacktrace code to find the original return
> | address from the FP alone.

Yes, I'm happy to update the changelog :)

Thanks!

> 
> Thanks,
> Mark.


-- 
Masami Hiramatsu <mhiramat@kernel.org>

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

  reply	other threads:[~2021-10-14 13:50 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-08 12:28 [PATCH 0/8] kprobes: Make KUnit and add stacktrace on kretprobe tests Masami Hiramatsu
2021-10-08 12:28 ` Masami Hiramatsu
2021-10-08 12:28 ` [PATCH 1/8] kprobes: convert tests to kunit Masami Hiramatsu
2021-10-08 12:28   ` Masami Hiramatsu
2021-10-08 12:28 ` [PATCH 2/8] kprobes: Add a test case for stacktrace from kretprobe handler Masami Hiramatsu
2021-10-08 12:28   ` Masami Hiramatsu
2021-10-08 12:28 ` [PATCH 3/8] arm64: kprobes: Record frame pointer with kretprobe instance Masami Hiramatsu
2021-10-08 12:28   ` Masami Hiramatsu
2021-10-13  8:14   ` Will Deacon
2021-10-13  8:14     ` Will Deacon
2021-10-13 10:01   ` Mark Rutland
2021-10-13 10:01     ` Mark Rutland
2021-10-14  8:04     ` Masami Hiramatsu
2021-10-14  8:04       ` Masami Hiramatsu
2021-10-14  9:13       ` Mark Rutland
2021-10-14  9:13         ` Mark Rutland
2021-10-14 10:01         ` Masami Hiramatsu
2021-10-14 10:01           ` Masami Hiramatsu
2021-10-14 10:27           ` Mark Rutland
2021-10-14 10:27             ` Mark Rutland
2021-10-14 13:50             ` Masami Hiramatsu [this message]
2021-10-14 13:50               ` Masami Hiramatsu
2021-10-08 12:28 ` [PATCH 4/8] arm64: kprobes: Make a frame pointer on __kretprobe_trampoline Masami Hiramatsu
2021-10-08 12:28   ` Masami Hiramatsu
2021-10-13  8:14   ` Will Deacon
2021-10-13  8:14     ` Will Deacon
2021-10-08 12:28 ` [PATCH 5/8] arm64: Recover kretprobe modified return address in stacktrace Masami Hiramatsu
2021-10-08 12:28   ` Masami Hiramatsu
2021-10-13  8:14   ` Will Deacon
2021-10-13  8:14     ` Will Deacon
2021-10-14  8:05     ` Masami Hiramatsu
2021-10-14  8:05       ` Masami Hiramatsu
2021-10-13 10:13   ` Mark Rutland
2021-10-13 10:13     ` Mark Rutland
2021-10-14  9:57     ` Masami Hiramatsu
2021-10-14  9:57       ` Masami Hiramatsu
2021-10-08 12:29 ` [PATCH 6/8] ARM: clang: Do not relay on lr register for stacktrace Masami Hiramatsu
2021-10-08 12:29   ` Masami Hiramatsu
2021-10-11 18:45   ` Nick Desaulniers
2021-10-11 18:45     ` Nick Desaulniers
2021-10-12 14:18     ` Masami Hiramatsu
2021-10-12 14:18       ` Masami Hiramatsu
2021-10-13 19:54       ` Nick Desaulniers
2021-10-13 19:54         ` Nick Desaulniers
2021-10-14 16:53   ` Russell King (Oracle)
2021-10-14 16:53     ` Russell King (Oracle)
2021-10-15  0:18     ` Masami Hiramatsu
2021-10-15  0:18       ` Masami Hiramatsu
2021-10-08 12:29 ` [PATCH 7/8] ARM: kprobes: Make a frame pointer on __kretprobe_trampoline Masami Hiramatsu
2021-10-08 12:29   ` Masami Hiramatsu
2021-10-11 19:06   ` Nick Desaulniers
2021-10-11 19:06     ` Nick Desaulniers
2021-10-08 12:29 ` [PATCH 8/8] ARM: Recover kretprobe modified return address in stacktrace Masami Hiramatsu
2021-10-08 12:29   ` Masami Hiramatsu

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=20211014225039.b96ff7b7fa86f340ceb50192@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=ananth@linux.ibm.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=mingo@kernel.org \
    --cc=nathan@kernel.org \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=ndesaulniers@google.com \
    --cc=rostedt@goodmis.org \
    --cc=svens@linux.ibm.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 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.