public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	linux-kernel@vger.kernel.org,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Seth Jennings <sjenning@redhat.com>
Subject: Re: [PATCH] kprobes: add kprobe_is_function_probed()
Date: Wed, 22 Oct 2014 15:54:53 +0900	[thread overview]
Message-ID: <544754BD.3010309@hitachi.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1410220800040.22681@pobox.suse.cz>

(2014/10/22 15:02), Jiri Kosina wrote:
> On Wed, 22 Oct 2014, Masami Hiramatsu wrote:
> 
>>> Add a function that allows external users (such as live patching 
>>> mechanisms) to check whether a given function (identified by symbol name) 
>>> has a kprobe installed in it.
>>
>> Actually, we've already exported the list of kprobes with probe points
>> (symbols) via debugfs. Please check /sys/kernel/debug/kprobes/list :)
> 
> Yes, I know, and kprobe_is_function_probed() is performing very similar 
> thing that show_kprobe_addr() is doing.
> But we'd like to be able to check this from within a kernel module (the 
> patch module) and issue WARN().
> 
> Otherwise we'll need to have a machinery in userspace before insmod which 
> will look up the functions in the module and compare them to the 
> debufs-provided interface.
> 
> Also, I don't think we want to be dependent on debugfs being mounted and 
> discoverable, etc ...

OK, and even if so, since there is no user of this function, at this point
we can not merge this. I'd like to wait until live patching.

BTW, if your tool is in kernel, you can use get_kprobe(addr) to check
there is kprobes on a given address. And of course you can use kallsyms
to get the address range of given function. Moreover, as Josh pointed,
there are several same name functions in kernel. I think this kind of
function should better provide address-base interface.

Thank you,

-- 
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-22  6:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-21 15:48 [PATCH] kprobes: add kprobe_is_function_probed() Jiri Kosina
2014-10-21 16:43 ` Josh Poimboeuf
2014-10-21 20:19   ` Jiri Kosina
2014-10-21 21:14     ` Josh Poimboeuf
2014-10-21 21:25       ` Jiri Kosina
2014-10-22  2:40         ` Josh Poimboeuf
2014-10-22 14:03           ` Seth Jennings
2014-10-21 16:48 ` Ananth N Mavinakayanahalli
2014-10-22  2:30 ` Masami Hiramatsu
2014-10-22  6:02   ` Jiri Kosina
2014-10-22  6:54     ` Masami Hiramatsu [this message]

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=544754BD.3010309@hitachi.com \
    --to=masami.hiramatsu.pt@hitachi.com \
    --cc=ananth@in.ibm.com \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=jkosina@suse.cz \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sjenning@redhat.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