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] BUG: xend oopses on munmap of /proc/xen/privcmd

To: Rik van Riel <riel@xxxxxxxxxx>
Subject: Re: [Xen-devel] BUG: xend oopses on munmap of /proc/xen/privcmd
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 26 Apr 2005 00:00:25 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 25 Apr 2005 23:02:16 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <Pine.LNX.4.61.0504251704110.5367@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <Pine.LNX.4.61.0504251704110.5367@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On 25 Apr 2005, at 23:29, Rik van Riel wrote:

This is with last night's Xen snapshot (apr 24th), on kernel
2.6.12-rc3 - but the mess is so horrid that I'm not quite sure
how to fix it...

This oops prevents xen from starting xenU domains.

Basically xend does the following:
1) mmap /proc/xen/privcmd
2) call an ioctl to populate the mmap
3) munmap the mapping created in (1)

Various people have been seeing this, although I haven't reproduced it on my own test box. The problem is not the munmap itself (although it obviously needs robustifying) but that something (presumably the ioctl) has mmaped bogus pages. The ioctl is only supposed to mmap the new domain's pages -- these will have pfn_valid() as false and so will not take the set_page_dirty() path in zap_pte_range.

It sounds to be related to my patch from Friday that removed redundant dom0_ops and changed xc_domain_create() to also call DOM0_SETMAXMEM and use dom_mem_op(MEMOP_increase_reservation) to actually reserve memory for the new domain. You might want to confirm this by 'bk cset -x'ing the changeset -- also, working from that end (the mmap end rather than the munmap end) you may have better luck making sense of what is going wrong. :-)

 -- Keir


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

<Prev in Thread] Current Thread [Next in Thread>