From: Masami Hiramatsu <mhiramat@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: ananth@in.ibm.com, prasanna@in.ibm.com,
anil.s.keshavamurthy@intel.com,
Jim Keniston <jkenisto@us.ibm.com>,
davem@davemloft.net, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][kprobes] support kretprobe-blacklist
Date: Fri, 17 Aug 2007 19:08:48 -0400 [thread overview]
Message-ID: <46C62A80.5040308@redhat.com> (raw)
In-Reply-To: <20070817150348.0f2f54da.akpm@linux-foundation.org>
Hi Andrew,
Thank you for comments.
Andrew Morton wrote:
>> Index: 2.6-mm/include/asm-i386/kprobes.h
>> ===================================================================
>> --- 2.6-mm.orig/include/asm-i386/kprobes.h
>> +++ 2.6-mm/include/asm-i386/kprobes.h
>> @@ -44,6 +44,7 @@ typedef u8 kprobe_opcode_t;
>>
>> #define ARCH_SUPPORTS_KRETPROBES
>> #define flush_insn_slot(p) do { } while (0)
>> +#define ARCH_SUPPORTS_KRETPROBE_BLACKLIST
>
> Can we avoid adding this please?
Yes, sure. I'll update my patch and eliminate those ifdefs.
> It should at least have been a CONFIG_foo thing, defined in arch/*/Kconfig.
>
> But that still requires nasty ifdefs in the C code. It would be very small
> overhead just to require that all architectures implement
> arch_kretprobe_blacklist[] (which can be renamed to kretprobe_blacklist[]).
> Architectures which don't need a blacklist can just have { { 0, 0 } }.
>
> If the few bytes of overhead on non-x86 really offends then one could do
> something like this:
>
> in powerpc header file:
>
> #define kretprobe_blacklist_size 0
>
> in x86 header file:
>
> extern const int kretprobe_blacklist_size;
>
> in x86 C file:
>
> const int kretprobe_blacklist_size = ARRAY_SIZE(kretprobe_blacklist);
It's looks very nice, thank you for the advice.
I think we can directly define "kretprobe_blacklist" as 0 in (for
example)ppc header instead of introducing "kretprobe_blacklist_size",
and check if "kretprobe_blacklist" is 0 or not in common code, is it OK?
> and then this code:
>
>> --- 2.6-mm.orig/kernel/kprobes.c
>> +++ 2.6-mm/kernel/kprobes.c
>> @@ -716,6 +716,18 @@ int __kprobes register_kretprobe(struct
>> int ret = 0;
>> struct kretprobe_instance *inst;
>> int i;
>> +#ifdef ARCH_SUPPORTS_KRETPROBE_BLACKLIST
>> + void *addr = rp->kp.addr;
>> +
>> + if (addr == NULL)
>> + kprobe_lookup_name(rp->kp.symbol_name, addr);
>> + addr += rp->kp.offset;
>> +
>> + for (i = 0; arch_kretprobe_blacklist[i].name != NULL; i++) {
>> + if (arch_kretprobe_blacklist[i].addr == addr)
>> + return -EINVAL;
>> + }
>> +#endif
>
> can be put inside
>
> if (kretprobe_blacklist_size) {
> ...
> }
>
> so the compiler will remove it all for (say) powerpc.
>
> There are lots of ways of doing it but code like this:
>
>> +#ifdef ARCH_SUPPORTS_KRETPROBE_BLACKLIST
>> + /* lookup the function address from its name */
>> + for (i = 0; arch_kretprobe_blacklist[i].name != NULL; i++) {
>> + kprobe_lookup_name(arch_kretprobe_blacklist[i].name,
>> + arch_kretprobe_blacklist[i].addr);
>> + if (!arch_kretprobe_blacklist[i].addr)
>> + printk("kretprobe: Unknown blacklisted function: %s\n",
>> + arch_kretprobe_blacklist[i].name);
>> + }
>> +#endif
>
> really isn't the sort of thing we like to see spreading through core kernel
> code.
>
> Have a think about it please, see what we can come up with?
OK, I see. I'll do that next time.
Best regards,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com, masami.hiramatsu.pt@hitachi.com
Tel: +1-978-392-2419
Tel: +1-508-982-2642 (cell phone)
Fax: +1-978-392-1001
next prev parent reply other threads:[~2007-08-17 23:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-17 19:43 [PATCH][kprobes] support kretprobe-blacklist Masami Hiramatsu
2007-08-17 22:03 ` Andrew Morton
2007-08-17 23:08 ` Masami Hiramatsu [this message]
2007-08-21 21:01 ` [PATCH][kprobes] support kretprobe-blacklist take2 Masami Hiramatsu
2007-08-23 4:12 ` Ananth N Mavinakayanahalli
2007-08-27 13:31 ` [PATCH][kprobes] support kretprobe-blacklist Christoph Hellwig
2007-08-27 15:49 ` Masami Hiramatsu
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=46C62A80.5040308@redhat.com \
--to=mhiramat@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ananth@in.ibm.com \
--cc=anil.s.keshavamurthy@intel.com \
--cc=davem@davemloft.net \
--cc=jkenisto@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=prasanna@in.ibm.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