From: Steven Rostedt <rostedt@goodmis.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
Kees Cook <keescook@chromium.org>, Ingo Molnar <mingo@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Alexei Starovoitov <ast@kernel.org>,
Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>,
"Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,
Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>,
"H . Peter Anvin" <hpa@zytor.com>,
Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
"David S . Miller" <davem@davemloft.net>,
Ian McDonald <ian.mcdonald@jandi.co.nz>,
Vlad Yasevich <vyasevich@gmail.com>,
Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs
Date: Mon, 9 Oct 2017 12:41:27 -0400 [thread overview]
Message-ID: <20171009124127.616e1fc3@gandalf.local.home> (raw)
In-Reply-To: <20171009103317.5701528f@lwn.net>
On Mon, 9 Oct 2017 10:33:17 -0600
Jonathan Corbet <corbet@lwn.net> wrote:
> On Mon, 9 Oct 2017 12:20:35 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > > > SAVE_REGS_IF_SUPPORTED - Similar to SAVE_REGS but the registering of a
> > > > ftrace_ops on an architecture that does not support passing of regs
> > > > will not fail with this flag set. But the callback must check if
> > > > regs is NULL or not to determine if the architecture supports it.
> > > >
> > > > RECURSION_SAFE - By default, a wrapper is added around the callback to
> > > > make sure that recursion of the function does not occur. That is
> > > > if a function within the callback itself is also traced, ftrace
> > >
> > > s/within the/called by the/
> >
> > I put in "within" because it is usually a function that is nested
> > within a function called by the callback. This bug has come up with
> > "gotchas", where some function that the callback calls has a path to a
> > function that was unexpectedly traced.
> >
> > The issue hasn't been caused by a function being traced that was
> > directly called by the callback. It is usually some deeper nested
> > function.
> >
> > I don't want to limit it to just checking functions that the callback
> > calls. Thoughts on how to stress this?
>
> "if a function that is called as a result of the callback's execution is
> also traced" ?
Sure, I'm not sure I could come up with a better way to say it.
>
> > > > IPMODIFY - Requires SAVE_REGS set. If the callback is to "hijack" the
> > > > traced function (have another function called instead of the traced
> > > > function), it requires setting this flag. This is what live kernel
> > > > patches uses. Without this flag the pt_regs->ip can not be modified.
> > > > Note, only one ftrace_ops with IPMODIFY set may be registered to
> > > > any given function at a time.
> > >
> > > I assume this requires being able to get the regs too?
> >
> > Yes, this is why I stated "Requires SAVE_REGS" which would pass the
> > regs to the callback. Should I rewrite that somehow?
>
> No, just ship me another cup of coffee and that one should be OK. Though
> perhaps if you'd spelled out the flag completely I wouldn't have been so
> dense :)
OK OK, I'll extend the names.
>
> > > > If a glob is used to set the filter, to remove unwanted matches the
> > > > ftrace_set_notrace() can also be used.
> > > >
> > > > int ftrace_set_notrace(struct ftrace_ops *ops, unsigned char *buf,
> > > > int len, int reset);
> > > >
> > > > This takes the same parameters as ftrace_set_filter() but will add the
> > > > functions it finds to not be traced. This doesn't remove them from the
> > > > filter itself, but keeps them from being traced. If @reset is set,
> > > > the filter is cleaded but the functions that match @buf will still not
> > >
> > > cleaded? :)
> >
> > Hmm, I'll have to be more descriptive.
> >
> > >
> > > > be traced (the callback will not be called on those functions).
> > >
> > > So how do you clead the "notrace" list?
> >
> > With passing in reset non-zero. I'll add that.
>
> My confusion remains here. The text says that if reset is "set", then the
> "notrace" list remains in place. So a non-zero "reset" value will remove
> previous notrace entries, along with the filter itself? So if you wanted
> to clear the notrace list entirely you would use buf="", reset=1? It would
> be good to be explicit there.
Ah I see what you mean. I'll try to be more explicit. A non-zero value
for reset means to clear the notrace buffer before making modifications.
In fact, I think the text is a bit more confusing, as I don't believe
that this function even modifies the "set_filter" list, even if reset
is set.
And yes, to clear all functions in either the set_filter or set_notrace
lists just pass in (&ops, NULL, 0, 1)
I'll start working on this document and post a real patch.
Thanks again for the review.
-- Steve
next prev parent reply other threads:[~2017-10-09 16:41 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-05 23:13 [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs Masami Hiramatsu
2017-10-05 23:13 ` [RFC PATCH -tip 1/5] kprobes: Use ENOTSUPP instead of ENOSYS Masami Hiramatsu
2017-10-20 8:57 ` Ingo Molnar
2017-10-20 15:51 ` Masami Hiramatsu
2017-10-05 23:14 ` [RFC PATCH -tip 2/5] kprobes: Abolish jprobe APIs Masami Hiramatsu
2017-10-20 12:26 ` [tip:perf/core] kprobes: Disable the jprobes APIs tip-bot for Masami Hiramatsu
2017-10-05 23:15 ` [RFC PATCH -tip 3/5] kprobes: Disable jprobe test code Masami Hiramatsu
2017-10-20 12:26 ` [tip:perf/core] kprobes: Disable the jprobes " tip-bot for Masami Hiramatsu
2017-10-05 23:15 ` [RFC PATCH -tip 4/5] kprobes: Remove jprobe sample code Masami Hiramatsu
2017-10-20 12:27 ` [tip:perf/core] kprobes: Remove the jprobes " tip-bot for Masami Hiramatsu
2017-10-05 23:16 ` [RFC PATCH -tip 5/5] kprobes: docs: Remove jprobe related document Masami Hiramatsu
2017-10-20 12:27 ` [tip:perf/core] kprobes/docs: Remove jprobes related documents tip-bot for Masami Hiramatsu
2017-10-05 23:35 ` [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs Kees Cook
2017-10-05 23:58 ` Steven Rostedt
2017-10-06 0:06 ` Kees Cook
2017-10-06 4:49 ` Masami Hiramatsu
2017-10-06 12:58 ` Steven Rostedt
2017-10-06 15:34 ` Steven Rostedt
2017-10-07 5:24 ` Stafford Horne
2017-10-09 16:48 ` Steven Rostedt
2017-10-07 8:55 ` Ingo Molnar
2017-10-09 16:45 ` Steven Rostedt
2017-10-07 9:35 ` Masami Hiramatsu
2017-10-09 16:59 ` Steven Rostedt
2017-10-09 15:33 ` Jonathan Corbet
2017-10-09 16:20 ` Steven Rostedt
2017-10-09 16:33 ` Jonathan Corbet
2017-10-09 16:41 ` Steven Rostedt [this message]
2017-10-09 18:10 ` Steven Rostedt
2017-10-10 14:02 ` Steven Rostedt
2017-10-06 0:32 ` Masami Hiramatsu
2017-10-06 1:11 ` Steven Rostedt
2017-10-06 4:47 ` Masami Hiramatsu
2017-10-20 12:22 ` Ingo Molnar
2017-10-20 13:32 ` Kees Cook
2017-10-20 15:17 ` Ingo Molnar
2017-10-20 16:28 ` Kees Cook
2017-10-21 8:06 ` Greg Kroah-Hartman
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=20171009124127.616e1fc3@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=ananth@linux.vnet.ibm.com \
--cc=anil.s.keshavamurthy@intel.com \
--cc=ast@kernel.org \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=hpa@zytor.com \
--cc=ian.mcdonald@jandi.co.nz \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=stephen@networkplumber.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vyasevich@gmail.com \
/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).