linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Julien Thierry <julien.thierry@arm.com>
To: Torsten Duwe <duwe@lst.de>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Ingo Molnar <mingo@redhat.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	Amit Daniel Kachhap <amit.kachhap@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, live-patching@vger.kernel.org
Subject: Re: [PATCH v7 2/3] arm64: implement ftrace with regs
Date: Thu, 7 Feb 2019 13:47:31 +0000	[thread overview]
Message-ID: <9bfb0506-5e8e-98d8-1946-9b6eaa4084b9@arm.com> (raw)
In-Reply-To: <20190207125159.GA19818@lst.de>



On 07/02/2019 12:51, Torsten Duwe wrote:
> On Thu, Feb 07, 2019 at 10:33:50AM +0000, Julien Thierry wrote:
>>
>>
>> On 06/02/2019 15:05, Torsten Duwe wrote:
>>> On Wed, Feb 06, 2019 at 08:59:44AM +0000, Julien Thierry wrote:
>>>> Hi Torsten,
>>>>
>>>> On 18/01/2019 16:39, Torsten Duwe wrote:
>>>>
>>>>> --- a/arch/arm64/kernel/ftrace.c
>>>>> +++ b/arch/arm64/kernel/ftrace.c
>>>>> @@ -133,17 +163,45 @@ int ftrace_make_call(struct dyn_ftrace *
>>>>>  	return ftrace_modify_code(pc, old, new, true);
>>>>>  }
>>>>>  
>>>>> +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
>>>>> +int ftrace_modify_call(struct dyn_ftrace *rec, unsigned long old_addr,
>>>>> +			unsigned long addr)
>>>>> +{
>>>>> +	unsigned long pc = rec->ip + REC_IP_BRANCH_OFFSET;
>>>>> +	u32 old, new;
>>>>> +
>>>>> +	old = aarch64_insn_gen_branch_imm(pc, old_addr, true);
>>>>> +	new = aarch64_insn_gen_branch_imm(pc, addr, true);
>>>>> +
>>>>> +	return ftrace_modify_code(pc, old, new, true);
>>>>> +}
>>>>> +#endif
>>>>> +
>>>>>  /*
>>>>>   * Turn off the call to ftrace_caller() in instrumented function
>>>>>   */
>>>>>  int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec,
>>>>>  		    unsigned long addr)
>>>>>  {
>>>>> -	unsigned long pc = rec->ip;
>>>>> +	unsigned long pc = rec->ip + REC_IP_BRANCH_OFFSET;
>>>>
>>>> Sorry to come back on this patch again, but I was looking at the ftrace
>>>> code a bit, and I see that when processing the ftrace call locations,
>>>> ftrace calls ftrace_call_adjust() on every ip registered as mcount
>>>> caller (or in our case patchable entries). This ftrace_call_adjust() is
>>>> arch specific, so I was thinking we could place the offset in here once
>>>> and for all so we don't have to worry about it in the future.
>>>
>>> Now that you mention it - yes indeed that's the correct facility to fix
>>> the deviating address, as Steve has also confirmed. I had totally forgotten
>>> about this hook.
>>>
>>>> Also, I'm unsure whether it would be safe, but we could patch the "mov
>>>> x9, lr" there as well. In theory, this would be called at init time
>>>> (before secondary CPUs are brought up) and when loading a module (so I'd
>>>> expect no-one is executing that code *yet*.
>>>>
>>>> If this is possible, I think it would make things a bit cleaner.
>>>
>>> This is in fact very tempting, but it will introduce a nasty side effect
>>> to ftrace_call_adjust. Is there any obvious documentation that specifies
>>> guarantees about ftrace_call_adjust being called exactly once for each site?
>>>
>>
>> I don't see really much documentation on that function. As far as I can
>> tell it is only called once for each site (and if it didn't, we'd always
>> be placing the same instruction, but I agree it wouldn't be nice). It
>> could depend on how far you can expand the notion of "adjusting" :) .
> 
> I've been thinking this over and I'm considering to make an ftrace_modify_code
> with verify and warn_once if it fails. Then read the insn back and bug_on
> should it not be the lr saver. Any objections?
> 

Hmmm, I'm not really convinced the read back + bug part would really be
useful right after patching this instruction in. ftrace_modify_code()
should already return an error if the instruction patching failed.

A real issue would be if ftrace_call_adjust() would be called on a
location where we shouldn't patch the instruction (i.e. a location that
is not the first instruction of a patchable entry). But to me, it
doesn't look like this function is intended to be called on something
else than the "mcount callsites" (which in our case is that first
patchable instruction).

Cheers,

-- 
Julien Thierry

  reply	other threads:[~2019-02-07 13:47 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-18 16:37 [PATCH v7 0/3] arm64: ftrace with regs Torsten Duwe
2019-01-18 16:39 ` [PATCH v7 1/3] arm64: replace -pg with CC_FLAGS_FTRACE in Makefiles Torsten Duwe
2019-01-18 17:24   ` Mark Rutland
2019-01-18 16:39 ` [PATCH v7 2/3] arm64: implement ftrace with regs Torsten Duwe
2019-01-22  1:39   ` Singh, Balbir
2019-01-22 13:09     ` Torsten Duwe
2019-01-23 20:38       ` Singh, Balbir
2019-01-22 10:18   ` Julien Thierry
2019-01-22 13:28     ` Torsten Duwe
2019-01-22 13:49       ` Julien Thierry
2019-01-22 13:55       ` Ard Biesheuvel
2019-02-04 12:03         ` Torsten Duwe
2019-02-04 13:43           ` Ard Biesheuvel
2019-02-06  8:59   ` Julien Thierry
2019-02-06  9:30     ` Julien Thierry
2019-02-06 14:09     ` Steven Rostedt
2019-02-06 15:05     ` Torsten Duwe
2019-02-07 10:33       ` Julien Thierry
2019-02-07 12:51         ` Torsten Duwe
2019-02-07 13:47           ` Julien Thierry [this message]
2019-02-07 14:51         ` Steven Rostedt
2019-02-07 14:58           ` Julien Thierry
2019-02-07 15:00           ` Torsten Duwe
2019-04-03  2:48   ` Mark Rutland
2019-04-03 12:30     ` Steven Rostedt
2019-04-03 13:05     ` Torsten Duwe
2019-01-18 16:39 ` [PATCH v7 3/3] arm64: use -fpatchable-function-entry if available Torsten Duwe

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=9bfb0506-5e8e-98d8-1946-9b6eaa4084b9@arm.com \
    --to=julien.thierry@arm.com \
    --cc=amit.kachhap@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=duwe@lst.de \
    --cc=jpoimboe@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=takahiro.akashi@linaro.org \
    --cc=will.deacon@arm.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: 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).