All of lore.kernel.org
 help / color / mirror / Atom feed
From: abelvesa@gmail.com (Abel Vesa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv4] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS
Date: Thu, 2 Mar 2017 21:01:24 +0000	[thread overview]
Message-ID: <20170302210124.GA9391@nuc> (raw)
In-Reply-To: <20170228115429.GC23251@nuc>

On Tue, Feb 28, 2017 at 11:54:29AM +0000, Abel Vesa wrote:
> On Tue, Feb 28, 2017 at 11:46:38AM +0000, Russell King - ARM Linux wrote:
> > On Tue, Feb 28, 2017 at 11:22:27AM +0000, Abel Vesa wrote:
> > > On Tue, Feb 28, 2017 at 11:58:49AM +0100, Nicolai Stange wrote:
> > > > Hi Abel,
> > > > 
> > > > On Tue, Feb 28 2017, Abel Vesa wrote:
> > > > 
> > > > > On Mon, Feb 27, 2017 at 04:52:06PM +0100, Nicolai Stange wrote:
> > > > >> On Fri, Feb 24 2017, Abel Vesa wrote:
> > > > >> Wouldn't it be better (and more consistent with other archs) to have
> > > > >> 
> > > > >>   pt_regs->ARM_lr = original lr
> > > > >>   pt_refs->ARM_pc = current lr
> > > > >> 
> > > > >> instead?
> > > > 
> > > > The stack would look like this then
> > > > 
> > > > @ ...           | ARM_ip | ARM_sp | ARM_lr      | ARM_pc      | ...          |
> > > > @ 0  4          48       52       56            60            64    68       72
> > > > @ R0 | R1 | ... | LR     | SP + 4 | original LR | original PC | PSR | OLD_R0 | original LR |
Just to make sure we're on the same page. If we are replacing the LR 
with the original_LR is it worth keeping around the one pushed before 
the ftrace_regs_caller is called?

Another thing, PC needs to be new_LR and then we can restore all 
regs r0 through r15 like this:

	ldmia   sp, {r0-r15}
> > > > 
> > > > I.e. the pt_regs would capture almost the full context of the
> > > > instrumented function (except for ip).
> > > > 
> > > So basicly what you are saying is:
> > > - instead of current LR save original LR (previous one saved in instrumented function epilog)
> > > - instead of current PC save original PC (previous one saved in instrumented function epilog)
> > > 
> > > I still don't see the point of saving the actual value of PC since nobody will ever
> > > restore it. In case of livepatch it will get overwritten anyway. As for LR, I agree,
> > > it could be the original one in pt_regs.
> > > 
> > > I'll look into this sometime today or tomorrow and get back with updates.
> > 
> > Which is exactly what I proposed, with code, on one of the previous
> > iterations of this patch...
> Fair enough. I probably missunderstood your comments then.
> 
> Thanks.
> > 
> > -- 
> > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> > according to speedtest.net.

WARNING: multiple messages have this Message-ID (diff)
From: Abel Vesa <abelvesa@gmail.com>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Nicolai Stange <nicstange@gmail.com>,
	Abel Vesa <abelvesa@linux.com>,
	robin.murphy@arm.com, jjhiblot@traphandler.com,
	Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@redhat.com>,
	pmladek@suse.com, mhiramat@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCHv4] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS
Date: Thu, 2 Mar 2017 21:01:24 +0000	[thread overview]
Message-ID: <20170302210124.GA9391@nuc> (raw)
In-Reply-To: <20170228115429.GC23251@nuc>

On Tue, Feb 28, 2017 at 11:54:29AM +0000, Abel Vesa wrote:
> On Tue, Feb 28, 2017 at 11:46:38AM +0000, Russell King - ARM Linux wrote:
> > On Tue, Feb 28, 2017 at 11:22:27AM +0000, Abel Vesa wrote:
> > > On Tue, Feb 28, 2017 at 11:58:49AM +0100, Nicolai Stange wrote:
> > > > Hi Abel,
> > > > 
> > > > On Tue, Feb 28 2017, Abel Vesa wrote:
> > > > 
> > > > > On Mon, Feb 27, 2017 at 04:52:06PM +0100, Nicolai Stange wrote:
> > > > >> On Fri, Feb 24 2017, Abel Vesa wrote:
> > > > >> Wouldn't it be better (and more consistent with other archs) to have
> > > > >> 
> > > > >>   pt_regs->ARM_lr = original lr
> > > > >>   pt_refs->ARM_pc = current lr
> > > > >> 
> > > > >> instead?
> > > > 
> > > > The stack would look like this then
> > > > 
> > > > @ ...           | ARM_ip | ARM_sp | ARM_lr      | ARM_pc      | ...          |
> > > > @ 0  4          48       52       56            60            64    68       72
> > > > @ R0 | R1 | ... | LR     | SP + 4 | original LR | original PC | PSR | OLD_R0 | original LR |
Just to make sure we're on the same page. If we are replacing the LR 
with the original_LR is it worth keeping around the one pushed before 
the ftrace_regs_caller is called?

Another thing, PC needs to be new_LR and then we can restore all 
regs r0 through r15 like this:

	ldmia   sp, {r0-r15}
> > > > 
> > > > I.e. the pt_regs would capture almost the full context of the
> > > > instrumented function (except for ip).
> > > > 
> > > So basicly what you are saying is:
> > > - instead of current LR save original LR (previous one saved in instrumented function epilog)
> > > - instead of current PC save original PC (previous one saved in instrumented function epilog)
> > > 
> > > I still don't see the point of saving the actual value of PC since nobody will ever
> > > restore it. In case of livepatch it will get overwritten anyway. As for LR, I agree,
> > > it could be the original one in pt_regs.
> > > 
> > > I'll look into this sometime today or tomorrow and get back with updates.
> > 
> > Which is exactly what I proposed, with code, on one of the previous
> > iterations of this patch...
> Fair enough. I probably missunderstood your comments then.
> 
> Thanks.
> > 
> > -- 
> > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> > according to speedtest.net.

  reply	other threads:[~2017-03-02 21:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-24 22:58 [PATCHv4] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS Abel Vesa
2017-02-24 22:58 ` Abel Vesa
2017-02-27 15:52 ` Nicolai Stange
2017-02-27 15:52   ` Nicolai Stange
2017-02-28  0:56   ` Abel Vesa
2017-02-28  0:56     ` Abel Vesa
2017-02-28 10:58     ` Nicolai Stange
2017-02-28 10:58       ` Nicolai Stange
2017-02-28 11:22       ` Abel Vesa
2017-02-28 11:22         ` Abel Vesa
2017-02-28 11:46         ` Russell King - ARM Linux
2017-02-28 11:46           ` Russell King - ARM Linux
2017-02-28 11:54           ` Abel Vesa
2017-02-28 11:54             ` Abel Vesa
2017-03-02 21:01             ` Abel Vesa [this message]
2017-03-02 21:01               ` Abel Vesa
2017-03-02 23:03               ` Russell King - ARM Linux
2017-03-02 23:03                 ` Russell King - ARM Linux

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=20170302210124.GA9391@nuc \
    --to=abelvesa@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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.