All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	Ingo Molnar <mingo@redhat.com>, Vojtech Pavlik <vojtech@suse.cz>,
	Jiri Kosina <jkosina@suse.cz>, Jiri Slaby <jslaby@suse.cz>,
	Steven Rostedt <rostedt@goodmis.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] kprobes: introduce ARCH_HANDLES_KPROBES_ON_FTRACE
Date: Tue, 21 Oct 2014 12:49:25 +0900	[thread overview]
Message-ID: <5445D7C5.1080006@hitachi.com> (raw)
In-Reply-To: <1413802794-38998-2-git-send-email-heiko.carstens@de.ibm.com>

(2014/10/20 19:59), Heiko Carstens wrote:
> Allow architectures to implement handling of kprobes on function
> tracer call sites on their own, without depending on common code.
> 
> This patch removes the kprobes check if a kprobe is being placed
> on a function tracer call site and therefore gives full responsibility
> of handling this correctly to the architecture.
> 
> This patch also introduces a user space visible change: if a kprobe
> is placed into the middle of an ftrace instruction the return value
> is changed from -EINVAL to -EILSEQ also for architectures which do
> not support KPROBES_ON_FTRACE.
> However in reality this change shouldn't matter at all.

Could you try to remove new kconfig by using a weak function?
This could be done with below functions:

In kernel/kprobes.c:

int __weak arch_check_ftrace_location(struct kprobe *p)
{
	unsigned long ftrace_addr = ftrace_location((unsigned long)p->addr);
	if (ftrace_addr) {
		...
}

And in arch/s390/kernel/kprobes.c:
int arch_check_ftrace_location(struct kprobe *p)
{
	return 0;
}

And in include/linux/kprobes.h
int arch_check_ftrace_location(struct kprobe *p);

Then, we don't need to add any macros or kconfigs.

Thank you,

> 
> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
> ---
>  arch/Kconfig     |  8 ++++++++
>  kernel/kprobes.c | 36 +++++++++++++++++++++---------------
>  2 files changed, 29 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 05d7a8a458d5..e1a8e0edf03f 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -85,6 +85,14 @@ config KPROBES_ON_FTRACE
>  	 passing of pt_regs to function tracing, then kprobes can
>  	 optimize on top of function tracing.
>  
> +config ARCH_HANDLES_KPROBES_ON_FTRACE
> +	def_bool n
> +	help
> +	 If an architecture can handle kprobes on function tracer call
> +	 sites on own, then this option should be selected. This option
> +	 removes the check which otherwise prevents to set kprobes on
> +	 function tracer call sites.
> +
>  config UPROBES
>  	def_bool n
>  	select PERCPU_RWSEM
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 3995f546d0f3..4b57fe9fbeb7 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -1410,28 +1410,34 @@ static inline int check_kprobe_rereg(struct kprobe *p)
>  	return ret;
>  }
>  
> -static int check_kprobe_address_safe(struct kprobe *p,
> -				     struct module **probed_mod)
> +static int check_ftrace_location(struct kprobe *p)
>  {
> -	int ret = 0;
>  	unsigned long ftrace_addr;
>  
> -	/*
> -	 * If the address is located on a ftrace nop, set the
> -	 * breakpoint to the following instruction.
> -	 */
>  	ftrace_addr = ftrace_location((unsigned long)p->addr);
> -	if (ftrace_addr) {
> -#ifdef CONFIG_KPROBES_ON_FTRACE
> -		/* Given address is not on the instruction boundary */
> -		if ((unsigned long)p->addr != ftrace_addr)
> -			return -EILSEQ;
> +	if (!ftrace_addr)
> +		return 0;
> +	/* Given address is not on the instruction boundary */
> +	if ((unsigned long)p->addr != ftrace_addr)
> +		return -EILSEQ;
> +	/* If an architecture handles kprobes on ftrace, we're done */
> +	if (IS_ENABLED(CONFIG_ARCH_HANDLES_KPROBES_ON_FTRACE))
> +		return 0;
> +	if (IS_ENABLED(CONFIG_KPROBES_ON_FTRACE)) {
>  		p->flags |= KPROBE_FLAG_FTRACE;
> -#else	/* !CONFIG_KPROBES_ON_FTRACE */
> -		return -EINVAL;
> -#endif
> +		return 0;
>  	}
> +	return -EINVAL;
> +}
> +
> +static int check_kprobe_address_safe(struct kprobe *p,
> +				     struct module **probed_mod)
> +{
> +	int ret;
>  
> +	ret = check_ftrace_location(p);
> +	if (ret)
> +		return ret;
>  	jump_label_lock();
>  	preempt_disable();
>  
> 


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com



  reply	other threads:[~2014-10-21  3:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-20 10:59 [PATCH v2 0/2] s390 vs. kprobes on ftrace Heiko Carstens
2014-10-20 10:59 ` [PATCH v2 1/2] kprobes: introduce ARCH_HANDLES_KPROBES_ON_FTRACE Heiko Carstens
2014-10-21  3:49   ` Masami Hiramatsu [this message]
2014-10-20 10:59 ` [PATCH v2 2/2] s390/ftrace,kprobes: allow to patch first instruction Heiko Carstens

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=5445D7C5.1080006@hitachi.com \
    --to=masami.hiramatsu.pt@hitachi.com \
    --cc=ananth@in.ibm.com \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=davem@davemloft.net \
    --cc=heiko.carstens@de.ibm.com \
    --cc=jkosina@suse.cz \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=vojtech@suse.cz \
    /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.