mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Ingo Molnar <mingo@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	x86@kernel.org, Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -tip v2 1/3] kprobes: Introduce nokprobe annotation for non-probe-able functions
Date: Fri, 1 Nov 2013 09:55:10 -0400	[thread overview]
Message-ID: <20131101095510.6b43aef5@gandalf.local.home> (raw)
In-Reply-To: <20131101112532.14657.34462.stgit@kbuild-fedora.novalocal>

On Fri, 01 Nov 2013 11:25:32 +0000
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> wrote:

> Instead of __kprobes annotation, introduce 'nokprobe' new annotation
> to annotate that the function is not probed by kprobes.
> 
> Previously the '__kprobes' is used just for avoiding probes on
> kprobes-related functions which will be used from kprobes. However
> nowadays we use it for prohibiting probing the functions implicitly
> invoked from kprobes int3 handler, since that causes infinit-loop
> lockup or sudden reboot. In this case, the annotated functions are
> not limited in the kprobes-related functions, and __kprobes looks
> very confusing. (Moreover, actually, most of control-side kprobes
> functions like as register_kprobes() are safely probed by kprobes)
> 
> Thus, we decide to introduce 'nokprobe' new annotation. We leave
> "__kprobes" just for compatibility but it should be replaced or
> removed eventually.
> 
> New commits must use 'nokprobe' for this purpose.
> 
> Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> ---
>  include/linux/compiler.h |    6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index 92669cd..173c64e 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -353,8 +353,10 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
>  
>  /* Ignore/forbid kprobes attach on very low level functions marked by this attribute: */
>  #ifdef CONFIG_KPROBES
> -# define __kprobes	__attribute__((__section__(".kprobes.text")))
> +# define nokprobe	__attribute__((__section__(".kprobes.text")))

I wonder if we should have both a __kprobes and nokprobe annotation,
such that we have:

# define __kprobes	__attribute__((__section__(".kprobes.text")))
# define nokprobe	__attribute__((__section__(".nokprobes.text")))

Then use __kprobes for the actual kprobes code, and nokprobe for all
the places that must not be traced by kprobes.

It just seems strange to me grouping kprobes code with non kprobes code.

-- Steve


>  #else
> -# define __kprobes
> +# define nokprobe
>  #endif
> +#define __kprobes nokprobe
> +
>  #endif /* __LINUX_COMPILER_H */
> 


  reply	other threads:[~2013-11-01 13:55 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-01 11:25 [PATCH -tip v2 0/3] kprobes: introduce nokprobe and updating blacklist Masami Hiramatsu
2013-11-01 11:25 ` [PATCH -tip v2 1/3] kprobes: Introduce nokprobe annotation for non-probe-able functions Masami Hiramatsu
2013-11-01 13:55   ` Steven Rostedt [this message]
2013-11-05  1:45     ` Masami Hiramatsu
2013-11-01 11:25 ` [PATCH -tip v2 2/3] [BUGFIX] kprobes/x86: Prohibit probing on debug_stack_* Masami Hiramatsu
2013-11-01 13:56   ` Steven Rostedt
2013-11-01 11:25 ` [PATCH -tip v2 3/3] [BUGFIX] kprobes: Prohibit probing on func_ptr_is_kernel_text Masami Hiramatsu
2013-11-01 13:57   ` Steven Rostedt
2013-11-05  2:00   ` Steven Rostedt
2013-11-05  3:15     ` Masami Hiramatsu
2013-11-05  6:09     ` Ingo Molnar
2013-11-05  6:59       ` Masami Hiramatsu
2013-11-05  7:05         ` Ingo Molnar
2013-11-05 11:38           ` Masami Hiramatsu
2013-11-05 12:35             ` Masami Hiramatsu
2013-11-06  6:07             ` Ingo Molnar
2013-11-06 10:34               ` Masami Hiramatsu
2013-11-06 11:50                 ` Ingo Molnar
2013-11-06 12:21               ` Steven Rostedt
2013-11-05 13:13           ` Steven Rostedt

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=20131101095510.6b43aef5@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=ananth@in.ibm.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®