lkml.org 
[lkml]   [2011]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v7 3.2-rc2 3/30] uprobes: register/unregister probes.
From
Date
On Tue, 2011-11-29 at 13:18 +0530, Srikar Dronamraju wrote:
> * Peter Zijlstra <peterz@infradead.org> [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.


\
 
 \ /
  Last update: 2011-11-29 11:55    [W:0.084 / U:8.480 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site