Re: [PATCH v5 3.1.0-rc4-tip 18/26] uprobes: slot allocation.

[Srikar Dronamraju]

* Peter Zijlstra <peterz@xxxxxxxxxxxxx> [2011-09-27 13:49:37]:

> On Tue, 2011-09-20 at 17:33 +0530, Srikar Dronamraju wrote:
> > +static int xol_add_vma(struct uprobes_xol_area *area)
> > +{
> > +       const struct cred *curr_cred;
> > +       struct vm_area_struct *vma;
> > +       struct mm_struct *mm;
> > +       unsigned long addr;
> > +       int ret = -ENOMEM;
> > +
> > +       mm = get_task_mm(current);
> > +       if (!mm)
> > +               return -ESRCH;
> > +
> > +       down_write(&mm->mmap_sem);
> > +       if (mm->uprobes_xol_area) {
> > +               ret = -EALREADY;
> > +               goto fail;
> > +       }
> > +
> > +       /*
> > +        * Find the end of the top mapping and skip a page.
> > +        * If there is no space for PAGE_SIZE above
> > +        * that, mmap will ignore our address hint.
> > +        *
> > +        * override credentials otherwise anonymous memory might
> > +        * not be granted execute permission when the selinux
> > +        * security hooks have their way.
> > +        */
> > +       vma = rb_entry(rb_last(&mm->mm_rb), struct vm_area_struct, vm_rb);
> > +       addr = vma->vm_end + PAGE_SIZE;
> > +       curr_cred = override_creds(&init_cred);
> > +       addr = do_mmap_pgoff(NULL, addr, PAGE_SIZE, PROT_EXEC, MAP_PRIVATE, 0);
> > +       revert_creds(curr_cred);
> > +
> > +       if (addr & ~PAGE_MASK)
> > +               goto fail;
> > +       vma = find_vma(mm, addr);
> > +
> > +       /* Don't expand vma on mremap(). */
> > +       vma->vm_flags |= VM_DONTEXPAND | VM_DONTCOPY;
> > +       area->vaddr = vma->vm_start;
> > +       if (get_user_pages(current, mm, area->vaddr, 1, 1, 1, &area->page,
> > +                               &vma) > 0)
> > +               ret = 0;
> > +
> > +fail:
> > +       up_write(&mm->mmap_sem);
> > +       mmput(mm);
> > +       return ret;
> > +} 
> 
> So is that the right way? I looked back to the previous discussion with
> Eric and couldn't really make up my mind either way. The changelog is
> entirely without detail and Eric isn't CC'ed.

This is based on what Stephen Smalley suggested on the same thread
https://lkml.org/lkml/2011/4/20/224

I used to keep the changelog after the marker after Christoph Hellwig
had suggested that https://lkml.org/lkml/2010/7/20/5
However "stg export" removes lines after the --- marker.

I agree that I should have copied Eric and Stephen atleast on this
patch. However if the number of to/cc are greater than 20, the LKML
archive cool ignore the mail.

I know that these arent problems faced by others and open to suggestions
on how they have overcome the same.

> 
> What's the point of having these discussions if all traces of them
> disappear on the next posting?

-- 
Thanks and Regards
Srikar

--
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/