WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Xen 4.0.1 "xc_map_foreign_batch: mmap failed: Cannot all

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Xen 4.0.1 "xc_map_foreign_batch: mmap failed: Cannot allocate memory"
From: "Charles Arnold" <carnold@xxxxxxxxxx>
Date: Thu, 06 Jan 2011 13:49:37 -0700
Cc: Jan Beulich <JBeulich@xxxxxxxxxx>, stefano.stabellini@xxxxxxxxxxxxx
Delivery-date: Tue, 11 Jan 2011 03:09:56 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 1/6/2011 at 10:14 AM, in message <4D25C782.5B74.0091.0@xxxxxxxxxx>, 
>>> Charles
Arnold wrote: 
> >>> On 1/6/2011 at 09:50 AM, in message
> <alpine.DEB.2.00.1101051748120.2390@kaball-desktop>, Stefano Stabellini
> <stefano.stabellini@xxxxxxxxxxxxx> wrote: 
>> On Wed, 5 Jan 2011, Charles Arnold wrote:
>>> No, just the usual mmap error.  See the attached logs.
>>> 
>>> As a reminder, the following conditions exist to duplicate the problem.
>>> Host: x86_64 sles11sp1.  Boot with dom0_mem=2048M, set 
> (enable-dom0-ballooning 
>> no) in xend-config.sxp
>>> Hypervisor: x86_64 Xen 4.0.1
>>> Guests: win2k3 (32bit) and win2k8r2 (64bit)
>>> The win2k8r2 guest uses robocopy to copy a 10 Gig file from the win2k3 
>> guest.  It copied about 23.2% before failing. 
>> 
>> (I should have read the subject more carefully)
>> 
>> xc_map_foreign_batch: mmap failed: Cannot allocate memory
>> 
>> That is an mmap error on the xch->fd file descriptor.
>> Considering that the privcmd mmap implementation sets the vma
>> VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP and always returns success
>> the ENOMEM must come from do_mmap.
>> It could be that sysctl_max_map_count has been reached but it is 65530
>> by default while the maximum number of buckets in the mapcache on 64
>> bits is only 10000.
>> Or the kernel could really be out of memory but in that case isn't a
>> little strange that we get the error from xc_map_foreign_batch?
>> 
>> I think we need to add more tracing in the dom0 kernel to figure out
>> what the problem is.
>> What dom0 kernel are you using?
> 
> uname -a
> Linux xen86 2.6.32.24-0.2-xen #1 SMP 2010-10-29 16:39:49 +0200 x86_64 x86_64 
> x86_64 GNU/Linux
> This is sles11sp1.
> 
>> Could you add some printk to the kernel source and try again?
>> A patch like the following should be enough.
> 
> Yes, I'll report back after building and testing.
> 

Attached is the messages file with the printk output.

- Charles

>> ---
>> 
>> 
>> 
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index b179abb..3f65277 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -991,16 +991,20 @@ unsigned long do_mmap_pgoff(struct file *file, 
>> unsigned 
> 
>> long addr,
>>  
>>      /* Careful about overflows.. */
>>      len = PAGE_ALIGN(len);
>> -    if (!len)
>> +    if (!len) {
>> +            printk("DEBUG PAGE_ALIGN ENOMEM\n");
>>              return -ENOMEM;
>> +    }
>>  
>>      /* offset overflow? */
>>      if ((pgoff + (len >> PAGE_SHIFT)) < pgoff)
>>                 return -EOVERFLOW;
>>  
>>      /* Too many mappings? */
>> -    if (mm->map_count > sysctl_max_map_count)
>> +    if (mm->map_count > sysctl_max_map_count) {
>> +            printk("DEBUG too many mappings ENOMEM\n");
>>              return -ENOMEM;
>> +    }
>>  
>>      /* Obtain the address to map to. we verify (or select) it and ensure
>>       * that it represents a valid section of the address space.
>> @@ -1231,14 +1235,18 @@ unsigned long mmap_region(struct file *file, 
>> unsigned 
> 
>> long addr,
>>  munmap_back:
>>      vma = find_vma_prepare(mm, addr, &prev, &rb_link, &rb_parent);
>>      if (vma && vma->vm_start < addr + len) {
>> -            if (do_munmap(mm, addr, len))
>> +            if (do_munmap(mm, addr, len)) {
>> +                    printk("DEBUG find_vma_prepare ENOMEM\n");
>>                      return -ENOMEM;
>> +            }
>>              goto munmap_back;
>>      }
>>  
>>      /* Check against address space limit. */
>> -    if (!may_expand_vm(mm, len >> PAGE_SHIFT))
>> +    if (!may_expand_vm(mm, len >> PAGE_SHIFT)) {
>> +            printk("DEBUG may_expand_vm ENOMEM\n");
>>              return -ENOMEM;
>> +    }
>>  
>>      /*
>>       * Set 'VM_NORESERVE' if we should not account for the
>> @@ -1259,8 +1267,10 @@ munmap_back:
>>       */
>>      if (accountable_mapping(file, vm_flags)) {
>>              charged = len >> PAGE_SHIFT;
>> -            if (security_vm_enough_memory(charged))
>> +            if (security_vm_enough_memory(charged)) {
>> +                    printk("DEBUG accountable_mapping ENOMEM\n");
>>                      return -ENOMEM;
>> +            }
>>              vm_flags |= VM_ACCOUNT;
>>      }
>>  
>> @@ -1278,6 +1288,7 @@ munmap_back:
>>       */
>>      vma = kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL);
>>      if (!vma) {
>> +            printk("DEBUG kmem_cache_zalloc ENOMEM\n");
>>              error = -ENOMEM;
>>              goto unacct_error;
>>      }
> 
> 

Attachment: messages
Description: Binary data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel