linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: dave.long@linaro.org (David Long)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v12 05/10] arm64: Kprobes with single stepping support
Date: Fri, 20 May 2016 01:16:33 -0400	[thread overview]
Message-ID: <573E9DB1.4070109@linaro.org> (raw)
In-Reply-To: <57349AE2.3060507@arm.com>

On 05/12/2016 11:01 AM, James Morse wrote:
> Hi David, Sandeepa,
>
> On 27/04/16 19:53, David Long wrote:
>> From: Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>
>
>> diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
>> new file mode 100644
>> index 0000000..dfa1b1f
>> --- /dev/null
>> +++ b/arch/arm64/kernel/kprobes.c
>> @@ -0,0 +1,520 @@
>> +/*
>> + * arch/arm64/kernel/kprobes.c
>> + *
>> + * Kprobes support for ARM64
>> + *
>> + * Copyright (C) 2013 Linaro Limited.
>> + * Author: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * General Public License for more details.
>> + *
>> + */
>> +#include <linux/kernel.h>
>> +#include <linux/kprobes.h>
>> +#include <linux/module.h>
>> +#include <linux/slab.h>
>> +#include <linux/stop_machine.h>
>> +#include <linux/stringify.h>
>> +#include <asm/traps.h>
>> +#include <asm/ptrace.h>
>> +#include <asm/cacheflush.h>
>> +#include <asm/debug-monitors.h>
>> +#include <asm/system_misc.h>
>> +#include <asm/insn.h>
>> +#include <asm/uaccess.h>
>> +
>> +#include "kprobes-arm64.h"
>> +
>> +#define MIN_STACK_SIZE(addr)	min((unsigned long)MAX_STACK_SIZE,	\
>> +	(unsigned long)current_thread_info() + THREAD_START_SP - (addr))
>
> What if we probe something called on the irq stack?
> This needs the on_irq_stack() checks too, the start/end can be found from the
> per-cpu irq_stack value.
>
> [ ... ]
>

OK.

>> +int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
>> +{
>> +	struct jprobe *jp = container_of(p, struct jprobe, kp);
>> +	struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
>> +	long stack_ptr = kernel_stack_pointer(regs);
>> +
>> +	kcb->jprobe_saved_regs = *regs;
>> +	memcpy(kcb->jprobes_stack, (void *)stack_ptr,
>> +	       MIN_STACK_SIZE(stack_ptr));
>
> I wonder if we need this stack save/restore?
>
> The comment next to the equivalent code for x86 says:
>> gcc assumes that the callee owns the argument space and could overwrite it,
>> e.g. tailcall optimization. So, to be absolutely safe we also save and
>> restore enough stack bytes to cover the argument area.
>
> On arm64 the first eight arguments are passed in registers, so we might not need
> this stack copy. (sparc and powerpc work like this too, their versions of this
> function don't copy chunks of the stack).
>
> ... then I went looking for functions with >8 arguments...
>
> Looking at the arm64 defconfig dwarf debug data, there are 71 of these that
> don't get inlined, picking at random:
>> rockchip_clk_register_pll() has 13
>> fib_dump_info() has 11
>> vma_merge() has 10
>> vring_create_virtqueue() has 10
> etc...
>
> So we do need this stack copying, so that we can probe these function without
> risking the arguments being modified.
>
> It may be worth including a comment to the effect that this stack save/restore
> is needed for functions that pass >8 arguments where the pre-handler may change
> these values on the stack.
>
>

I can add a comment.

>> +	preempt_enable_no_resched();
>> +	return 1;
>> +}
>> +
>
>
> Thanks,
>
> James
>

Thanks,
-dl

  parent reply	other threads:[~2016-05-20  5:16 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-27 18:52 [PATCH v12 00/10] arm64: Add kernel probes (kprobes) support David Long
2016-04-27 18:52 ` [PATCH v12 01/10] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature David Long
2016-04-28 16:08   ` Marc Zyngier
2016-05-13 19:07     ` David Long
2016-05-17  9:14   ` Huang Shijie
2016-05-20  4:18     ` David Long
2016-04-27 18:52 ` [PATCH v12 02/10] arm64: Add more test functions to insn.c David Long
2016-04-27 18:52 ` [PATCH v12 03/10] arm64: add conditional instruction simulation support David Long
2016-04-27 18:52 ` [PATCH v12 04/10] arm64: Blacklist non-kprobe-able symbols David Long
2016-04-27 18:53 ` [PATCH v12 05/10] arm64: Kprobes with single stepping support David Long
2016-05-12 15:01   ` James Morse
2016-05-18  4:04     ` Masami Hiramatsu
2016-05-20  5:16     ` David Long [this message]
2016-05-17  8:58   ` Huang Shijie
2016-05-18  3:29     ` Masami Hiramatsu
2016-05-26 19:25       ` David Long
2016-05-26 15:40     ` David Long
2016-05-17  9:10   ` Huang Shijie
2016-06-01  5:15     ` David Long
2016-04-27 18:53 ` [PATCH v12 06/10] arm64: Treat all entry code as non-kprobe-able David Long
2016-05-12 14:49   ` James Morse
2016-05-20  5:28     ` David Long
2016-05-26 15:26     ` David Long
2016-04-27 18:53 ` [PATCH v12 07/10] arm64: kprobes instruction simulation support David Long
2016-05-19  1:52   ` Huang Shijie
2016-05-26 19:28     ` David Long
2016-04-27 18:53 ` [PATCH v12 08/10] arm64: Add trampoline code for kretprobes David Long
2016-04-27 18:53 ` [PATCH v12 09/10] arm64: Add kernel return probes support (kretprobes) David Long
2016-04-27 18:53 ` [PATCH v12 10/10] kprobes: Add arm64 case in kprobe example module David Long
2016-05-17  9:57   ` Huang Shijie
2016-05-17 10:24     ` Mark Brown
2016-05-18  1:31       ` Huang Shijie
2016-05-11 15:33 ` [PATCH v12 00/10] arm64: Add kernel probes (kprobes) support James Morse
2016-05-12  2:26   ` Li Bin
2016-05-13 20:02     ` David Long
2016-05-18  2:24     ` Huang Shijie

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=573E9DB1.4070109@linaro.org \
    --to=dave.long@linaro.org \
    --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).