linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 5/8] arm64: kprobes instruction simulation support
Date: Wed, 24 Feb 2016 15:21:15 +0000	[thread overview]
Message-ID: <56CDCA6B.7000207@arm.com> (raw)
In-Reply-To: <56CDC734.4000201@linaro.org>

On 24/02/16 15:07, David Long wrote:
> On 02/24/2016 04:05 AM, Marc Zyngier wrote:
>> On Wed, 24 Feb 2016 01:56:52 -0500
>> David Long <dave.long@linaro.org> wrote:
>>
>>> On 02/19/2016 09:04 AM, Marc Zyngier wrote:
>>>> Hi David,
>>>>
>>>> On 18/02/16 23:48, David Long wrote:
>>>>> From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>>>>>
>>>>> Kprobes needs simulation of instructions that cannot be stepped
>>>>> from different memory location, e.g.: those instructions
>>>>> that uses PC-relative addressing. In simulation, the behaviour
>>>>> of the instruction is implemented using a copy of pt_regs.
>>>>>
>>>>> Following instruction catagories are simulated:
>>>>>    - All branching instructions(conditional, register, and immediate)
>>>>>    - Literal access instructions(load-literal, adr/adrp)
>>>>>
>>>>> Conditional execution is limited to branching instructions in
>>>>> ARM v8. If conditions at PSTATE do not match the condition fields
>>>>> of opcode, the instruction is effectively NOP. Kprobes considers
>>>>> this case as 'miss'.
>>>>>
>>>>> This code also replaces the use of arch/arm/opcodes.c for
>>>>> arm_check_condition().
>>>>>
>>>>> Thanks to Will Cohen for assorted suggested changes.
>>>>>
>>>>> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>>>>> Signed-off-by: William Cohen <wcohen@redhat.com>
>>>>> Signed-off-by: David A. Long <dave.long@linaro.org>
>>
>> [...]
>>
>>>>> +};
>>>>> +
>>>>> +asmlinkage unsigned int __kprobes arm_check_condition(u32 opcode, u32 psr)
>>>>
>>>> Why asmlinkage? This function is never called from assembly code on arm64.
>>>>
>>>
>>> This comes from the 32-bit ARM code that tests the condition from
>>> entry.S.  We include arch/arm/include/asm/opcodes.h in
>>> arch/arm64/include/asm/opcodes.h so it gets declared there with
>>> asmlinkage. I can remove the asmlinkage in the actual function
>>> definition and it still compiles but I'm not sure that is kosher.
>>
>> asmlinkage is only meaningful if you're calling it from assembly code.
>> As you seem to only call it from C code, having asmlinkage is both
>> pointless and confusing.
>>
>>> Will Deacon was advocating getting rid of the include of the 32-bit header
>>> file but it looked to me like this would mean a lot of duplicated
>>> defines and the work would be mostly unrelated to kprobes.
>>
>> Arguably, arm_check_condition() (which only matters to 32bit code,
>> hence userspace) is also completely unrelated to kprobes. I still think
>> Will's point stands.
>>
> 
> Yes, I would not argue about that cross-architecture include needing to 
> be fixed.  Can I assume you agree that need not be a part of this 
> kprobes patch though, nor a prerequisite patch for it?

My usual stand on this kind of issue is that if you start digging in the
middle of the road, you're also responsible for cleaning the pavement
(sorry if that's a bad analogy).

In the end, this is the arm64 maintainers that decide what they want to
see, and by the look of it, Will has made his point clear...

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

  reply	other threads:[~2016-02-24 15:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-18 23:48 [PATCH 0/8] arm64: Add kernel probes (kprobes) support David Long
2016-02-18 23:48 ` [PATCH 1/8] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature David Long
2016-02-18 23:48 ` [PATCH 2/8] arm64: Add more test functions to insn.c David Long
2016-02-18 23:48 ` [PATCH 3/8] arm64: add copy_to/from_user to kprobes blacklist David Long
2016-02-18 23:48 ` [PATCH 4/8] arm64: Kprobes with single stepping support David Long
2016-02-18 23:48 ` [PATCH 5/8] arm64: kprobes instruction simulation support David Long
2016-02-19 14:04   ` Marc Zyngier
2016-02-24  6:56     ` David Long
2016-02-24  9:05       ` Marc Zyngier
2016-02-24 15:07         ` David Long
2016-02-24 15:21           ` Marc Zyngier [this message]
2016-03-01  2:55             ` David Long
2016-02-18 23:48 ` [PATCH 6/8] arm64: Add trampoline code for kretprobes David Long
2016-02-18 23:48 ` [PATCH 7/8] arm64: Add kernel return probes support (kretprobes) David Long
2016-02-18 23:48 ` [PATCH 8/8] kprobes: Add arm64 case in kprobe example module David Long

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=56CDCA6B.7000207@arm.com \
    --to=marc.zyngier@arm.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 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).