From: Masami Hiramatsu <mhiramat@kernel.org>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>,
Thomas Gleixner <tglx@linutronix.de>,
"H . Peter Anvin" <hpa@zytor.com>,
Andrey Konovalov <andreyknvl@google.com>,
Andy Lutomirski <luto@kernel.org>
Subject: Re: [PATCH tip/master v4] kprobes: extable: Identify kprobes' insn-slots as kernel text area
Date: Tue, 10 Jan 2017 10:11:01 +0900 [thread overview]
Message-ID: <20170110101101.f2dacdd07154725a943c7bb9@kernel.org> (raw)
In-Reply-To: <20170109173648.k7dxu7nz22qc6upq@treble>
On Mon, 9 Jan 2017 11:36:48 -0600
Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> On Sun, Jan 08, 2017 at 11:58:09PM +0900, Masami Hiramatsu wrote:
> > Make __kernel_text_address()/kernel_text_address() returns
> > true if the given address is on a kprobe's instruction slot,
> > which is generated by kprobes as a trampoline code.
> > This can help stacktraces to determine the address is on a
> > text area or not.
> >
> > To implement this without any sleep in is_kprobe_*_slot(),
> > this also modify insn_cache page list as a rcu list. It may
> > increase processing deley (not processing time) for garbage
> > slot collection, because it requires to wait an additional
> > rcu grance period when freeing a page from the list.
> > However, since it is not a hot path, we may not take care of it.
> >
> > Note: this can give a small overhead to stack unwinders because
> > this adds 2 checks in __kernel_text_address(). However, the
> > impact should be very small, kprobe_insn_pages list has 1 entry
> > per 256 probes(on x86, on arm/arm64 it will be 1024 probes),
> > and kprobe_optinsn_pages has 1 entry per 32 probes(on x86).
> > In most use cases, the number of kprobe events may be less
> > than 20, this means is_kprobe_*_slot() will check just 1 entry.
> >
> > Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
>
> Thanks for doing this Masami! I verified that it works:
>
> Tested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Thanks!
>
> I suspect that BPF generated code also has the same issue, so I'll leave
> the unwinder warning disabled for now.
>
> BTW, I think we'll have more problems with generated code if/when we
> move to an x86 DWARF unwinder, because it won't have any idea how to
> unwind past generated code. Long term I wonder if it would make sense
> to create some kind of framework for creating or registering generated
> code, so we can solve these types of problems in a single place.
Agreed. I think that can also help us to make the generated code RO :).
Thank you,
--
Masami Hiramatsu <mhiramat@kernel.org>
next prev parent reply other threads:[~2017-01-10 1:11 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-22 6:42 Detecting kprobes generated code addresses Josh Poimboeuf
2016-12-25 3:13 ` Masami Hiramatsu
2016-12-25 6:16 ` Masami Hiramatsu
2016-12-26 4:30 ` Masami Hiramatsu
2016-12-26 14:50 ` [PATCH tip/master] kprobes: extable: Identify kprobes' insn-slots as kernel text area Masami Hiramatsu
2016-12-26 15:34 ` [PATCH tip/master v2] " Masami Hiramatsu
2016-12-26 17:21 ` kbuild test robot
2016-12-26 17:46 ` kbuild test robot
2016-12-27 6:13 ` Masami Hiramatsu
2016-12-27 6:14 ` [PATCH tip/master v3] " Masami Hiramatsu
2017-01-03 10:54 ` Peter Zijlstra
2017-01-04 5:06 ` Masami Hiramatsu
2017-01-04 10:01 ` Peter Zijlstra
2017-01-08 4:22 ` Masami Hiramatsu
2017-01-08 12:31 ` Masami Hiramatsu
2017-01-08 14:58 ` [PATCH tip/master v4] " Masami Hiramatsu
2017-01-09 17:36 ` Josh Poimboeuf
2017-01-10 1:11 ` Masami Hiramatsu [this message]
2017-01-10 8:59 ` Peter Zijlstra
2017-01-10 21:42 ` Josh Poimboeuf
2017-01-11 9:57 ` Masami Hiramatsu
2017-01-14 9:56 ` [tip:perf/core] kprobes, extable: Identify kprobes trampolines " tip-bot for Masami Hiramatsu
2017-01-04 14:21 ` [PATCH tip/master v3] kprobes: extable: Identify kprobes' insn-slots " 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=20170110101101.f2dacdd07154725a943c7bb9@kernel.org \
--to=mhiramat@kernel.org \
--cc=ananth@linux.vnet.ibm.com \
--cc=andreyknvl@google.com \
--cc=hpa@zytor.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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.