Re: [PATCH v7 3.2-rc2 3/30] uprobes: register/unregister probes.

From: Peter Zijlstra
Date: Tue Nov 29 2011 - 05:53:10 EST


On Tue, 2011-11-29 at 13:18 +0530, Srikar Dronamraju wrote:
> * Peter Zijlstra <peterz@xxxxxxxxxxxxx> [2011-11-28 16:29:54]:
>
> > On Fri, 2011-11-18 at 16:37 +0530, Srikar Dronamraju wrote:
> > > +static void __unregister_uprobe(struct inode *inode, loff_t offset,
> > > + struct uprobe *uprobe)
> > > +{
> > > + struct list_head try_list;
> > > + struct address_space *mapping;
> > > + struct vma_info *vi, *tmpvi;
> > > + struct vm_area_struct *vma;
> > > + struct mm_struct *mm;
> > > + loff_t vaddr;
> > > +
> > > + mapping = inode->i_mapping;
> > > + INIT_LIST_HEAD(&try_list);
> > > + while ((vi = find_next_vma_info(&try_list, offset,
> > > + mapping, false)) != NULL) {
> > > + if (IS_ERR(vi))
> > > + break;
> >
> > So what kind of half-assed state are we left in if we try an unregister
> > under memory pressure and how do we deal with that?
> >
>
> Agree, Even I had this concern and wanted to see if there are ways to
> deal with this.

If you do have this, please mention it in the Changelog and/or put /*
XXX */ in the code or so to point it out that there's a problem here.

> Do you have any other approaches that we could try?

You could use the stuff from patch 29 to effectively disable the uprobe
and return -ENOMEM to whoemever is unregistering. Basically failing the
unreg.

That way you can leave the uprobe in existance and half installed but
functionally fully disabled. Userspace (assuming we go back that far)
can then either re-try the removal later, or even reinstate it by doing
a register again or so.

Its still not pretty, but its better than pretending the unreg
completed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/