Messages in this thread |  | | Date | Tue, 21 Oct 2014 22:19:30 +0200 (CEST) | From | Jiri Kosina <> | Subject | Re: [PATCH] kprobes: add kprobe_is_function_probed() |
| |
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
|  |