> On Apr 18, 2018, at 7:25 AM, Steven Rostedt <rost...@goodmis.org> wrote: > > On Wed, 18 Apr 2018 16:03:42 +0200 > Miklos Szeredi <mik...@szeredi.hu> wrote: > >>> @@ -937,7 +928,8 @@ probe_event_enable(struct trace_uprobe *tu, struct >>> trace_event_file *file, >>> goto err_flags; >>> >>> tu->consumer.filter = filter; >>> - ret = uprobe_register(tu->inode, tu->offset, &tu->consumer); >>> + ret = uprobe_register(d_inode(tu->path.dentry), tu->offset, >>> + &tu->consumer); >> >> It is not entirely clear how the lifetime of uprobe relates to the >> lifetime of trace_uprobe. Is the uprobe object never going to survive >> its creator trace_uprobe object? > > Not exactly sure what you mean here. > > The trace_uprobe (the probe event) is created, it doesn't do anything > until it is enabled. This function is called when it is enabled. The > trace_uprobe (probe event) can not be deleted while it is enabled > (EBUSY). > > Are you asking what happens if the file is deleted while it has probe? > That I don't know about (haven't tried it out). But I would hope that > it keeps a reference to the inode, isn't that what the igrab is for? > And is now being replaced by a reference on the path, or is that the > problem? > > -- Steve >
Just as Miklos pointed out, I run tests with the uprobe and confirmed that igrab() is not sufficient to prevent umount. When we change it to path_get()/path_put(), umount will abort because of the trace_uprobe. Song >> >> If that's the case, it warrants a comment. If that's not the case, >> then the path would need to be passed to uprobe_resister() which would >> need to obtain its own reference. >> >>> if (ret) >>> goto err_buffer; >>>
