Re: [PATCH] kprobes: add kprobe_is_function_probed()

[Jiri Kosina]

On Tue, 21 Oct 2014, Josh Poimboeuf 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.
> 
> Functions aren't uniquely identifiable by name.  Perhaps it should be
> something like kprobe_is_addr_range_probed()?

Hi Josh,

first, thanks a lot for the review.

This is a rather difficult call actually. I am of course aware of the fact 
that kernel fucntions can't be uniquely identified by name, but when 
thinking about this, one has to consider:

- ftrace primary userspace interface (set_ftrace_filter) is based on 
  function names
- kprobe tracer and uprobe trace primary userspace interface 
  (/sys/kernel/debug/tracing/kprobe_events and uprobe_events respectively)
  are primarily based on function names
- the number of conflicts is probably zero, or very close to zero. Try to 
  run this 

	cut -f3 -d' ' /proc/kallsyms | sort  | uniq -c

  So it's questionable whether all the back and forth name->address->name 
  translations all over the place are worth all the trouble.

  I do agree though that we should make it obvious that the lookup 
  interface works on symbol names only ... perhaps by adding '_by_name()' 
  or so?

> Should we refuse to patch a function which has a kprobe installed inside 
> it?  

I think warning about it is a good thing to do.

> Is there a race-free way to do that?

Do we need to be race-free here? If userspace is both instantiating new 
krpobe and initiating live kernel patching at the "same time", I don't 
think kernel should try to solve such race ... it's simply there by 
definition, depending on, for example, scheduling decisions.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/