All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.