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/
Home Products Support Community News


[Xen-bugs] [Bug 1166] New: kernel BUG while mprotect()'ing

To: xen-bugs@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-bugs] [Bug 1166] New: kernel BUG while mprotect()'ing
From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
Date: Thu, 7 Feb 2008 16:23:55 -0800
Delivery-date: Thu, 07 Feb 2008 16:24:04 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-bugs-request@lists.xensource.com?subject=help>
List-id: Xen Bugzilla <xen-bugs.lists.xensource.com>
List-post: <mailto:xen-bugs@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-bugs>, <mailto:xen-bugs-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-bugs>, <mailto:xen-bugs-request@lists.xensource.com?subject=unsubscribe>
Reply-to: bugs@xxxxxxxxxxxxxxxxxx
Sender: xen-bugs-bounces@xxxxxxxxxxxxxxxxxxx

           Summary: kernel BUG while mprotect()'ing
           Product: Xen
           Version: unstable
          Platform: x86
        OS/Version: Linux-2.6
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Guest-OS
        AssignedTo: xen-bugs@xxxxxxxxxxxxxxxxxxx
        ReportedBy: jon.winters2@xxxxxxxxx

I encountered the following bug when trying to start X on Xen unstable (as of
c/s 16981) and linux (as of c/s 406).  I used strace to distill
the bug down to a set of simple syscalls: open, mmap, close, and two
mprotect's.  A sample program that causes the bug is included below.

kernel BUG at include2/asm/mach-xen/asm/maddr.h:34!
invalid opcode: 0000 [#1]
Modules linked in: rtc usbcore dm_mod tsdev
CPU: 0
EIP: 0061:[<c011d7ad>] Not tainted VLI
EFLAGS: 00010246 ( #2)
EIP is at xen_change_pte_range+0x36d/0x3a0
eax: 000766d6 ebx: 80000000 ecx: 000766d6 edx: 00000000
esi: 766d6025 edi: 00000000 ebp: ebcdda08 esp: ec13fcd8
ds: 007b es: 007b ss: 0069
Process test_program (pid: 6533, ti=ec13e000 task=ed76b240 task.ti=ec13e000)
Stack: c1000000 ec13fcf4 c1579bac 00000000 00000000 b7f41000 ebc14df8 532dda0a
       00000000 766d60a0 00000000 00000000 00000000 00000000 00000000 00000000
       00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Call Trace:
 [<c024a358>] __add_entropy_words+0x68/0x1b0
 [<c024a9f8>] extract_buf+0xb8/0x100
 [<c0198ac4>] __d_lookup+0xa4/0x110
 [<c018d692>] do_lookup+0x42/0x90
 [<c0197b8d>] dput+0x1d/0x150
 [<c018e171>] __link_path_walk+0xa91/0xeb0
 [<c015c7b0>] buffered_rmqueue+0x50/0x1e0
 [<c015cad4>] get_page_from_freelist+0xc4/0x110
 [<c0168b73>] apply_to_page_range+0x2b3/0x450
 [<c015c687>] free_hot_cold_page+0x1e7/0x210
 [<c011baa5>] xen_tlb_flush_all+0x25/0x40
 [<c020e699>] prio_tree_insert+0x119/0x1b0
 [<c016e538>] change_protection+0x158/0x1f0
 [<c016e706>] mprotect_fixup+0x136/0x1e0
 [<c016e93b>] sys_mprotect+0x18b/0x230
 [<c0105967>] syscall_call+0x7/0xb
Code: ff 09 d3 89 c8 83 c8 01 89 da e9 ef fc ff ff 0f 0b 48 02 04 98 37 c0 eb
94 a1 80 82 49 c0 e9 2f fe ff ff 39 c1 0f 82 a6 fe ff <0f> 0b 22 00 30 6b 37 c0
e9 99 fe ff ff 8d b6 00 00 00 00 a1 80
EIP: [<c011d7ad>] xen_change_pte_range+0x36d/0x3a0 SS:ESP 0069:ec13fcd8


#include <assert.h>
#include <fcntl.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>

int main()
   int fd;
   char *mapped_memory;
   int retval;

   fd = open("/dev/mem", O_RDWR);
   assert(fd != -1);

   // 0xe0000000 is the address of the video card's ring buffer but the bug
happens just as well when
   // the address is 0x0
   mapped_memory = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, fd,
   assert(mapped_memory != (char *)-1);

   retval = close(fd);
   assert (retval == 0);

   retval = mprotect(mapped_memory, 4096, PROT_NONE);
   assert(retval == 0);

   // this next call triggers the bug
   retval = mprotect(mapped_memory, 4096, PROT_READ); 
   assert(retval == 0);

   return 0;

Things of note:
1.) this bug does not occur in Xen 3.0.2-2 with linux 2.6.16-xen
2.) if you put a printk at maddr.h:34 (i.e. the line BUG_ON(max_mapnr && pfn >=
max_mapnr), you find out that pfn is _equal_ to max_mapnr, which is causing the
bug to trigger
3.) the kernel configuration is the same as the default configuration except
that support for ext3, SCSI devices, SATA, AHCI SATA, Intel PIIX/ICH SATA, and
the Intel PIIXn PCI IDE chipset are built-in instead of modules
4.) the computer is a Dell Inspiron 1420N laptop with an Intel 82801H chipset
(ICH8 Family) and the 965GM graphics chipset
5.) I don't see how the call trace above makes sense (i.e. how does
__add_entropy_words result in the calling of xen_change_pte_range), but then
again I am not experienced in kernel debugging; if I could understand the call
trace, then I would put more printk's in to try to trace back the bug further

Let me know if you need any other information / need me to try anything else. 
Hope this helps.

Configure bugmail: 
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Xen-bugs mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-bugs] [Bug 1166] New: kernel BUG while mprotect()'ing, bugzilla-daemon <=