Depending on the argument 'add', uprobe_apply() may be registering or
unregistering a probe. The current comment misses the description of the
registration.
Signed-off-by: Zhen Lei <redacted>
---
kernel/events/uprobes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Depending on the argument 'add', uprobe_apply() may be registering or
unregistering a probe.
...
/*
- * uprobe_apply - unregister an already registered probe.
- * @inode: the file in which the probe has to be removed.
+ * uprobe_apply - register a probe or unregister an already registered probe.
Not really.
See the commit 3c83a9ad0295eb63bd ("uprobes: make uprobe_register() return struct uprobe *")
in tip/perf/core which changed this description
* uprobe_apply - add or remove the breakpoints according to @uc->filter
still looks confusing, yes...
Oleg.
Depending on the argument 'add', uprobe_apply() may be registering or
unregistering a probe.
...
quoted
/*
- * uprobe_apply - unregister an already registered probe.
- * @inode: the file in which the probe has to be removed.
+ * uprobe_apply - register a probe or unregister an already registered probe.
Not really.
See the commit 3c83a9ad0295eb63bd ("uprobes: make uprobe_register() return struct uprobe *")
in tip/perf/core which changed this description
* uprobe_apply - add or remove the breakpoints according to @uc->filter
still looks confusing, yes...
OK, I got it. I mistakenly thought the comment was based on register_for_each_vma.
It seems necessary to rename 'register_for_each_vma' to 'apply_for_each_vma',
or some other more appropriate name.