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:5.188 / U:0.300 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site