On Wed, Apr 18, 2018 at 4:25 PM, Steven Rostedt <[email protected]> wrote: > On Wed, 18 Apr 2018 16:03:42 +0200 > Miklos Szeredi <[email protected]> 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?
No, that's not the problem. What I don't see is how the uprobe object relates to the trace_uprobe object. Because after the patch the uprobe object still only has a ref to the inode, and that can lead to the same issue as with trace_uprobe. OTOH if uprobe can't survive its creating trace_uprobe, then it doesn't need to take a ref to the inode at all, since trace_uprobe already holds it. Taking an extra ref isn't incorrect, it's just unnecessary and confusing. So this needs to be cleared up in some way. Thanks, Miklos
