| Message ID | 20170831183215.4306-1-naveen.n.rao@linux.vnet.ibm.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | uprobe: Warn if unable to install breakpoint | expand |
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes: > When we try to install a uprobe breakpoint in uprobe_mmap(), we ignore > all errors encountered in the process per this comment at the top of > the function: > /* > * Called from mmap_region/vma_adjust with mm->mmap_sem acquired. > * > * Currently we ignore all errors and always return 0, the callers > * can't handle the failure anyway. > */ > > However, this is very confusing for users since no probe hits are > recorded nor is an error logged in dmesg. > > Fix this by logging an error in dmesg so that users can discover that > there was an issue with the uprobe. To facilitate use of uprobe_warn(), > we move that function to the top of the file. > > With this patch, we see a message similar to this in dmesg: > [ 201.449213] uprobe: uprobe_t:9740 failed to setup probe at 0x95c (-524) > > Reported-by: Anton Blanchard <anton@samba.org> > Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> > --- > kernel/events/uprobes.c | 21 ++++++++++++++------- > 1 file changed, 14 insertions(+), 7 deletions(-) > > diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c > index 0e137f98a50c..587c591a535c 100644 > --- a/kernel/events/uprobes.c > +++ b/kernel/events/uprobes.c > @@ -112,6 +112,12 @@ struct xol_area { > unsigned long vaddr; /* Page(s) of instruction slots */ > }; > > +static void uprobe_warn(struct task_struct *t, const char *msg) > +{ > + pr_warn("uprobe: %s:%d failed to %s\n", > + current->comm, current->pid, msg); That should probably be ratelimited no? cheers
On 2017/09/01 03:09PM, Michael Ellerman wrote: > "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes: > > > When we try to install a uprobe breakpoint in uprobe_mmap(), we ignore > > all errors encountered in the process per this comment at the top of > > the function: > > /* > > * Called from mmap_region/vma_adjust with mm->mmap_sem acquired. > > * > > * Currently we ignore all errors and always return 0, the callers > > * can't handle the failure anyway. > > */ > > > > However, this is very confusing for users since no probe hits are > > recorded nor is an error logged in dmesg. > > > > Fix this by logging an error in dmesg so that users can discover that > > there was an issue with the uprobe. To facilitate use of uprobe_warn(), > > we move that function to the top of the file. > > > > With this patch, we see a message similar to this in dmesg: > > [ 201.449213] uprobe: uprobe_t:9740 failed to setup probe at 0x95c (-524) > > > > Reported-by: Anton Blanchard <anton@samba.org> > > Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> > > --- > > kernel/events/uprobes.c | 21 ++++++++++++++------- > > 1 file changed, 14 insertions(+), 7 deletions(-) > > > > diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c > > index 0e137f98a50c..587c591a535c 100644 > > --- a/kernel/events/uprobes.c > > +++ b/kernel/events/uprobes.c > > @@ -112,6 +112,12 @@ struct xol_area { > > unsigned long vaddr; /* Page(s) of instruction slots */ > > }; > > > > +static void uprobe_warn(struct task_struct *t, const char *msg) > > +{ > > + pr_warn("uprobe: %s:%d failed to %s\n", > > + current->comm, current->pid, msg); > > That should probably be ratelimited no? Uprobes can only be installed by root today, so it is not as bad. But, I do agree that it is good to ratelimit. I will send a subsequent patch to do this. Thanks for the review, - Naveen
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c index 0e137f98a50c..587c591a535c 100644 --- a/kernel/events/uprobes.c +++ b/kernel/events/uprobes.c @@ -112,6 +112,12 @@ struct xol_area { unsigned long vaddr; /* Page(s) of instruction slots */ }; +static void uprobe_warn(struct task_struct *t, const char *msg) +{ + pr_warn("uprobe: %s:%d failed to %s\n", + current->comm, current->pid, msg); +} + /* * valid_vma: Verify if the specified vma is an executable vma * Relax restrictions while unregistering: vm_flags might have @@ -1087,7 +1093,14 @@ int uprobe_mmap(struct vm_area_struct *vma) if (!fatal_signal_pending(current) && filter_chain(uprobe, UPROBE_FILTER_MMAP, vma->vm_mm)) { unsigned long vaddr = offset_to_vaddr(vma, uprobe->offset); - install_breakpoint(uprobe, vma->vm_mm, vma, vaddr); + int ret = install_breakpoint(uprobe, vma->vm_mm, vma, vaddr); + if (ret) { + char msg[64]; + snprintf(msg, sizeof(msg), + "setup probe at 0x%llx (%d)", + uprobe->offset, ret); + uprobe_warn(current, (const char *)msg); + } } put_uprobe(uprobe); } @@ -1470,12 +1483,6 @@ static int dup_utask(struct task_struct *t, struct uprobe_task *o_utask) return 0; } -static void uprobe_warn(struct task_struct *t, const char *msg) -{ - pr_warn("uprobe: %s:%d failed to %s\n", - current->comm, current->pid, msg); -} - static void dup_xol_work(struct callback_head *work) { if (current->flags & PF_EXITING)
When we try to install a uprobe breakpoint in uprobe_mmap(), we ignore all errors encountered in the process per this comment at the top of the function: /* * Called from mmap_region/vma_adjust with mm->mmap_sem acquired. * * Currently we ignore all errors and always return 0, the callers * can't handle the failure anyway. */ However, this is very confusing for users since no probe hits are recorded nor is an error logged in dmesg. Fix this by logging an error in dmesg so that users can discover that there was an issue with the uprobe. To facilitate use of uprobe_warn(), we move that function to the top of the file. With this patch, we see a message similar to this in dmesg: [ 201.449213] uprobe: uprobe_t:9740 failed to setup probe at 0x95c (-524) Reported-by: Anton Blanchard <anton@samba.org> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> --- kernel/events/uprobes.c | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-)