Re: What's does KPROBE_ENTRY mean?

[Paul Mundt <lethal@linux-sh.org>]

On Thu, Jul 26, 2007 at 02:50:38PM +0800, jidong xiao wrote:
> Thanks.So if I don't care any probes, and I actually don't need to
> take use of kprobes, then I can use the functions defined through
> KPROBE_ENTRY() the same way as those defined via ENTRY(), right?
> 
Yes, there's nothing special about KPROBE_ENTRY() other than the section
placement. It even wraps in to ENTRY() after the .pushsection.

As you can see from kernel/kprobes.c:

	static int __kprobes in_kprobes_functions(unsigned long addr)
	{
		if (addr >= (unsigned long)__kprobes_text_start &&
		    addr < (unsigned long)__kprobes_text_end)
			return -EINVAL;
		return 0;
	}


...

and in __register_kprobe():

        if (!kernel_text_address((unsigned long) p->addr) ||
            in_kprobes_functions((unsigned long) p->addr))
                return -EINVAL;

So the only behavioural change for these symbols is that insertion of
probes is prohibited. There is nothing inherently special about them
otherwise, and platforms that don't enable kprobes aren't going to
care either.

One curious thing is that while KPROBE_ENTRY() unconditionally does
a .pushsection .kprobes.text, __kprobes does this conditionally
depending on CONFIG_KPROBES. While this doesn't hurt anything, it's
inconsistent to say the least. We should probably either make __kprobes
explicitly always use .kprobes.text, or just wrap KPROBE_ENTRY to ENTRY
directly and forego the .pushsection when CONFIG_KPROBES=n.