On Mon, May 21, 2012 at 2:37 PM, Andrew Morton
<akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> hm, we seem to have conflicting commits between mainline and linux-next.
> During the merge window. Again. Nobody knows why this happens.
I didn't have my trivial cleanup branches in linux-next, I'm afraid.
Usually my pending cleanups are just small patches that I carry along
without even committing them, this time around I had slightly more
than that.
>
> static void unmap_single_vma(struct mmu_gather *tlb,
> struct vm_area_struct *vma, unsigned long start_addr,
> unsigned long end_addr,
> struct zap_details *details)
> {
> unsigned long start = max(vma->vm_start, start_addr);
> unsigned long end;
>
> if (start >= vma->vm_end)
> return;
> end = min(vma->vm_end, end_addr);
> if (end <= vma->vm_start)
> return;
>
> <<<<<<< HEAD
> =======
> if (vma->vm_file)
> uprobe_munmap(vma, start, end);
>
> if (vma->vm_flags & VM_ACCOUNT)
> *nr_accounted += (end - start) >> PAGE_SHIFT;
>
>>>>>>>> linux-next/akpm-base
Just remove the VM_ACCOUNT and *nr_accounted lines - they're done in
the caller now. They always should have been, I'm not sure why it was
in the "walk the page tables" path, which has nothing to do with it.
That said, I think that's true of uprobes too. Why the f*ck would
uprobes do it's "munmap" operation when we walk the page tables? This
function was called by more than just the actual unmapping, it was
called by stuff that wants to zap the pages but leave the mapping
around.
So that uprobe_munmap() could probably also be better moved into the
caller - where we actually remove the vma. Maybe.
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href