All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
To: mhiramat@kernel.org, Peter Zijlstra <peterz@infradead.org>
Cc: ananth@linux.ibm.com, Christoph Hellwig <hch@lst.de>,
	linux-kernel@vger.kernel.org, mingo@kernel.org,
	rostedt@goodmis.org, x86@kernel.org
Subject: Re: [PATCH 1/2] kprobes: Remove kprobe::fault_handler
Date: Wed, 26 May 2021 16:20:25 +0530	[thread overview]
Message-ID: <1622025445.6q8nl3t4ap.naveen@linux.ibm.com> (raw)
In-Reply-To: <20210525073213.561116662@infradead.org>

Peter Zijlstra wrote:
> The reason for kprobe::fault_handler(), as given by their comment:
> 
>  * We come here because instructions in the pre/post
>  * handler caused the page_fault, this could happen
>  * if handler tries to access user space by
>  * copy_from_user(), get_user() etc. Let the
>  * user-specified handler try to fix it first.
> 
> Is just plain bad. Those other handlers are ran from non-preemptible
> context and had better use _nofault() functions. Also, there is no
> upstream usage of this.
> 
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> ---
>  Documentation/trace/kprobes.rst    |   24 +++++-------------------
>  arch/arc/kernel/kprobes.c          |   10 ----------
>  arch/arm/probes/kprobes/core.c     |    9 ---------
>  arch/arm64/kernel/probes/kprobes.c |   10 ----------
>  arch/csky/kernel/probes/kprobes.c  |   10 ----------
>  arch/ia64/kernel/kprobes.c         |    9 ---------
>  arch/mips/kernel/kprobes.c         |    3 ---
>  arch/powerpc/kernel/kprobes.c      |   10 ----------
>  arch/riscv/kernel/probes/kprobes.c |   10 ----------
>  arch/s390/kernel/kprobes.c         |   10 ----------
>  arch/sh/kernel/kprobes.c           |   10 ----------
>  arch/sparc/kernel/kprobes.c        |   10 ----------
>  arch/x86/kernel/kprobes/core.c     |   10 ----------
>  include/linux/kprobes.h            |    8 --------
>  kernel/kprobes.c                   |   19 -------------------
>  samples/kprobes/kprobe_example.c   |   15 ---------------
>  16 files changed, 5 insertions(+), 172 deletions(-)
> 

<snip>

> --- a/arch/x86/kernel/kprobes/core.c
> +++ b/arch/x86/kernel/kprobes/core.c
> @@ -947,16 +947,6 @@ int kprobe_fault_handler(struct pt_regs
>  		 * these specific fault cases.
>  		 */
>  		kprobes_inc_nmissed_count(cur);

Not necessarily related, but I'm wondering why we're incrementing the 
probe miss count here. Unlike what the comment above indicates, this is 
not a 'fault' counter, but just a count of the number of times the probe 
handler wasn't called.

> -
> -		/*
> -		 * We come here because instructions in the pre/post
> -		 * handler caused the page_fault, this could happen
> -		 * if handler tries to access user space by
> -		 * copy_from_user(), get_user() etc. Let the
> -		 * user-specified handler try to fix it first.
> -		 */
> -		if (cur->fault_handler && cur->fault_handler(cur, regs, trapnr))
> -			return 1;
>  	}


- Naveen


  parent reply	other threads:[~2021-05-26 10:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-25  7:25 [PATCH 0/2] kprobes: Remove kprobe::fault_handler Peter Zijlstra
2021-05-25  7:25 ` [PATCH 1/2] " Peter Zijlstra
2021-05-25 14:06   ` Masami Hiramatsu
2021-05-26 10:50   ` Naveen N. Rao [this message]
2021-05-26 13:51     ` Masami Hiramatsu
2021-06-01 12:01   ` [PATCH] kprobes: Do not increment probe miss count in the fault handler Naveen N. Rao
2021-06-01 13:20     ` Peter Zijlstra
2021-06-01 23:48       ` Masami Hiramatsu
2021-06-04 13:38     ` [tip: perf/core] " tip-bot2 for Naveen N. Rao
2021-06-01 14:04   ` [tip: perf/core] kprobes: Remove kprobe::fault_handler tip-bot2 for Peter Zijlstra
2021-05-25  7:25 ` [PATCH 2/2] x86,kprobes: WARN if kprobes tries to handle a fault Peter Zijlstra
2021-05-25 14:21   ` Masami Hiramatsu
2021-06-01 14:04   ` [tip: perf/core] " tip-bot2 for Peter Zijlstra

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=1622025445.6q8nl3t4ap.naveen@linux.ibm.com \
    --to=naveen.n.rao@linux.vnet.ibm.com \
    --cc=ananth@linux.ibm.com \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=x86@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 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.