From: Mark Rutland <mark.rutland@arm.com>
To: Amit Kachhap <amit.kachhap@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org, catalin.marinas@arm.com,
deller@gmx.de, duwe@suse.de,
James.Bottomley@HansenPartnership.com, james.morse@arm.com,
jeyu@kernel.org, jpoimboe@redhat.com, jthierry@redhat.com,
linux-parisc@vger.kernel.org, mingo@redhat.com,
peterz@infradead.org, svens@stackframe.org,
takahiro.akashi@linaro.org, will@kernel.org
Subject: Re: [PATCHv2 1/8] ftrace: add ftrace_init_nop()
Date: Wed, 6 Nov 2019 14:15:30 +0000 [thread overview]
Message-ID: <20191106141530.GC50610@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <8e68de1f-f961-752d-9c07-ce41ce624d35@arm.com>
On Tue, Nov 05, 2019 at 12:17:26PM +0530, Amit Kachhap wrote:
> On 11/4/19 7:06 PM, Mark Rutland wrote:
> > On Sat, Nov 02, 2019 at 05:49:00PM +0530, Amit Daniel Kachhap wrote:
> > > On 10/29/19 10:28 PM, Mark Rutland wrote:
> > > > +/**
> > > > + * ftrace_init_nop - initialize a nop call site
> > > > + * @mod: module structure if called by module load initialization
> > > > + * @rec: the call site record (e.g. mcount/fentry)
> > > > + *
> > > > + * This is a very sensitive operation and great care needs
> > > > + * to be taken by the arch. The operation should carefully
> > > > + * read the location, check to see if what is read is indeed
> > > > + * what we expect it to be, and then on success of the compare,
> > > > + * it should write to the location.
> > > > + *
> > > > + * The code segment at @rec->ip should contain the contents created by
> > > > + * the compiler
> > > Nit: Will it be better to write it as "@rec->ip should store the adjusted
> > > ftrace entry address of the call site" or something like that.
> >
> > This was the specific wording requested by Steve, and it's trying to
> > describe the instructions at rec->ip, rather than the value of rec->ip,
> > so I think it's better to leave this as-is.
> ok Its fine this way too. Actually from the comment, I could not understand
> which one of the compiler contents this points to as in this case there are
> 2 nops.
We can't say what the compiler contents will be. An architecture may use
this callback if it's using mcount, mfentry, patchable-function-entry,
or some other mechanism we're not aware of today. Depending on the
architecture and mechanism, the callsite could contain a number of
distinct things.
All the comment is trying to say is that when ftrace_init_nop() is
called, the callsite has not been modified in any way since being
compiled, so we can expect the contents to be whatever the compiler
generated.
Thanks,
Mark.
next prev parent reply other threads:[~2019-11-06 14:15 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-29 16:58 [PATCHv2 0/8] arm64: ftrace cleanup + FTRACE_WITH_REGS Mark Rutland
2019-10-29 16:58 ` [PATCHv2 1/8] ftrace: add ftrace_init_nop() Mark Rutland
2019-10-30 15:00 ` Miroslav Benes
2019-11-02 12:19 ` Amit Daniel Kachhap
2019-11-04 13:11 ` Steven Rostedt
2019-11-05 6:59 ` Amit Kachhap
2019-11-04 13:36 ` Mark Rutland
2019-11-05 6:47 ` Amit Kachhap
2019-11-06 14:15 ` Mark Rutland [this message]
2019-11-07 4:40 ` Amit Kachhap
2019-11-04 13:16 ` Steven Rostedt
2019-11-04 13:38 ` Mark Rutland
2019-11-04 13:53 ` Steven Rostedt
2019-10-29 16:58 ` [PATCHv2 2/8] module/ftrace: handle patchable-function-entry Mark Rutland
2019-10-30 15:03 ` Torsten Duwe
2019-10-31 9:02 ` Mark Rutland
2019-10-31 11:42 ` Torsten Duwe
2019-10-31 13:00 ` Mark Rutland
2019-11-04 13:28 ` Steven Rostedt
2019-11-04 14:00 ` Mark Rutland
2019-11-04 13:25 ` Steven Rostedt
2019-11-04 15:51 ` Mark Rutland
2019-11-04 20:58 ` Helge Deller
2019-11-05 8:59 ` Miroslav Benes
2019-10-29 16:58 ` [PATCHv2 3/8] arm64: module: rework special section handling Mark Rutland
2019-10-30 15:25 ` Miroslav Benes
2019-10-29 16:58 ` [PATCHv2 4/8] arm64: module/ftrace: intialize PLT at load time Mark Rutland
2019-11-02 12:20 ` Amit Daniel Kachhap
2019-11-04 13:55 ` Mark Rutland
2019-10-29 16:58 ` [PATCHv2 5/8] arm64: insn: add encoder for MOV (register) Mark Rutland
2019-10-29 16:58 ` [PATCHv2 6/8] arm64: asm-offsets: add S_FP Mark Rutland
2019-10-29 16:58 ` [PATCHv2 7/8] arm64: implement ftrace with regs Mark Rutland
2019-11-02 12:21 ` Amit Daniel Kachhap
2019-11-04 13:51 ` Mark Rutland
[not found] ` <CANW9uyug8WKN2fR-FmcW-C_OO_OQ_AvukM+BR7wqiJ9eFQMO9Q@mail.gmail.com>
2019-11-15 7:45 ` Torsten Duwe
2019-11-15 13:59 ` Mark Rutland
2019-10-29 16:58 ` [PATCHv2 8/8] arm64: ftrace: minimize ifdeffery Mark Rutland
2019-10-30 17:02 ` [PATCHv2 0/8] arm64: ftrace cleanup + FTRACE_WITH_REGS Torsten Duwe
2019-10-31 17:16 ` Torsten Duwe
2019-11-01 9:08 ` Mark Rutland
2019-11-01 15:39 ` Sven Schnelle
2019-11-01 16:28 ` Mark Rutland
2019-11-02 12:12 ` Amit Daniel Kachhap
2019-11-04 12:56 ` Will Deacon
2019-11-04 13:03 ` Amit Kachhap
2019-11-04 14:04 ` Mark Rutland
2019-11-05 7:06 ` Amit Kachhap
2019-11-07 11:31 ` Catalin Marinas
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=20191106141530.GC50610@lakrids.cambridge.arm.com \
--to=mark.rutland@arm.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=amit.kachhap@arm.com \
--cc=catalin.marinas@arm.com \
--cc=deller@gmx.de \
--cc=duwe@suse.de \
--cc=james.morse@arm.com \
--cc=jeyu@kernel.org \
--cc=jpoimboe@redhat.com \
--cc=jthierry@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=svens@stackframe.org \
--cc=takahiro.akashi@linaro.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: 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;
as well as URLs for NNTP newsgroup(s).