Hi Ravi, sorry for delay! I am trying to recall what this code should do ;) At first glance, I do not see any serious problem in this version... except it doesn't apply to Linus's tree. just one question for now. On 04/17, Ravi Bangoria wrote: > > @@ -941,6 +1091,9 @@ typedef bool (*filter_func_t)(struct uprobe_consumer *self, > if (ret) > goto err_buffer; > > + if (tu->ref_ctr_offset) > + sdt_increment_ref_ctr(tu); > + iiuc, this is probe_event_enable()... Looks racy, but afaics the race with uprobe_mmap() will be closed by the next change. However, it seems that probe_event_disable() can race with trace_uprobe_mmap() too and the next 7/9 patch won't help, > + if (tu->ref_ctr_offset) > + sdt_decrement_ref_ctr(tu); > + > uprobe_unregister(tu->inode, tu->offset, &tu->consumer); > tu->tp.flags &= file ? ~TP_FLAG_TRACE : ~TP_FLAG_PROFILE; so what if trace_uprobe_mmap() comes right after uprobe_unregister() ? Note that trace_probe_is_enabled() is T until we update tp.flags. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
