All of lore.kernel.org
 help / color / mirror / Atom feed
From: akuster <akuster@mvista.com>
To: Ingo Oeser <ioe-lkml@rameria.de>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [patch 1/1] MM:  detach_vmas_to_be_unmapped fix
Date: Fri, 23 Feb 2007 08:27:00 -0800	[thread overview]
Message-ID: <45DF15D4.6040403@mvista.com> (raw)
In-Reply-To: <200702212159.07295.ioe-lkml@rameria.de>



Ingo Oeser wrote:
> Hi,
> 
> On Wednesday, 21. February 2007, akuster@mvista.com wrote:
>> ---
>>
>>  mm/mmap.c |    4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff -puN mm/mmap.c~Avoiding-mmap-fragmentation_fixup mm/mmap.c
>> --- linux-2.6_clean/mm/mmap.c~Avoiding-mmap-fragmentation_fixup	2007-02-21 09:49:32.000000000 -0800
>> +++ linux-2.6_clean-akuster/mm/mmap.c	2007-02-21 09:51:26.000000000 -0800
>> @@ -1720,9 +1720,9 @@ detach_vmas_to_be_unmapped(struct mm_str
>>  	*insertion_point = vma;
>>  	tail_vma->vm_next = NULL;
>>  	if (mm->unmap_area == arch_unmap_area)
>> -		addr = prev ? prev->vm_end : mm->mmap_base;
>> +		addr = prev ? prev->vm_start : mm->mmap_base;
>>  	else
>> -		addr = vma ?  vma->vm_start : mm->mmap_base;
>> +		addr = vma ?  vma->vm_end : mm->mmap_base;
>>  	mm->unmap_area(mm, addr);
>>  	mm->mmap_cache = NULL;		/* Kill the cache. */
>>  }
> 
> Please comment, why you think this is necessary.

Yes that would help.

On Feb. 16th I asked a question and got no response. Here is what should 
have been included with the above patch.

Wolfgang Wander submitted a fix to address a mmap fragmentation issue. 
The git patch ( 1363c3cd8603a913a27e2995dccbd70d5312d8e6 ) is somewhat 
different and yields different results when running Wolfgang's test case 
leakme.c.

IMHO, the vm start and end address are swapped in arch_unmap_area and 
arch_unmap_area_topdown functions.

Prior to this patch arch_unmap_area() used area->vm_start and 
arch_unmap_area_topdown used area->vm_end in the git patch the following 
change showed up.

if (mm->unmap_area == arch_unmap_area)
     addr = prev ? prev->vm_start : mm->mmap_base;
else
     addr = vma ?  vma->vm_end : mm->mmap_base;

Using Wolfgang Wander's leakme.c test, I get the same results seen with 
his original "Avoiding mmap fragmentation" patch as I do after swapping 
  the start & end address in the above code segment. The patch I 
submitted  addresses this typo issue.

TIA,
Armin

> 
> 
> Thanks & Regards
> 
> Ingo Oeser

  reply	other threads:[~2007-02-23 16:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-21 18:06 [patch 1/1] MM: detach_vmas_to_be_unmapped fix akuster
2007-02-21 20:59 ` Ingo Oeser
2007-02-23 16:27   ` akuster [this message]
2007-02-27 20:27     ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45DF15D4.6040403@mvista.com \
    --to=akuster@mvista.com \
    --cc=akpm@osdl.org \
    --cc=ioe-lkml@rameria.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.