Messages in this thread | | | Date | Mon, 30 Jun 2014 19:50:25 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH 4/4] tracing/uprobes: Fix the usage of uprobe_buffer_enable() in probe_event_enable() |
| |
On 06/30, Srikar Dronamraju wrote: > > > The usage of uprobe_buffer_enable() added by dcad1a20 is very wrong, > > > > 1. uprobe_buffer_enable() and uprobe_buffer_disable() are not balanced, > > _enable() should be called only if !enabled. > > > > 2. If uprobe_buffer_enable() fails probe_event_enable() should clear > > tp.flags and free event_file_link. > > > > 3. If uprobe_register() fails it should do uprobe_buffer_disable(). > > > > Signed-off-by: Oleg Nesterov <oleg@redhat.com> > > Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Thanks!
> (one nit .. ) > > > + ret = uprobe_buffer_enable(); > > + if (ret) > > + goto err_flags; > > + > > tu->consumer.filter = filter; > > ret = uprobe_register(tu->inode, tu->offset, &tu->consumer); > > - if (ret) { > > - if (file) { > > - list_del(&link->list); > > - kfree(link); > > - tu->tp.flags &= ~TP_FLAG_TRACE; > > - } else > > - tu->tp.flags &= ~TP_FLAG_PROFILE; > > - } > > + if (ret) > > + goto err_buffer; > > > > + return 0; > > + > > + err_buffer: > > + uprobe_buffer_disable(); > > + > > How about avoiding err_buffer label? > + if (!ret) > + return 0; > > + uprobe_buffer_disable(); > +
Well, I do not really mind. But to me it looks more consistent this way, if-something-fail-goto-err_label.
IOW, I think that the code should either not use err-labels, or always use them like above.
Besides, perhaps we will add "if (file) uprobe_apply()" after _register() to mix perf/ftrace, then we will need to change this "if (!ret)" code again.
Oleg.
| |