NetBSD Problem Report #39335

From tron@zhadum.org.uk  Sun Aug 10 14:41:22 2008
Return-Path: <tron@zhadum.org.uk>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id E967963BB81
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 10 Aug 2008 14:41:21 +0000 (UTC)
Message-Id: <200808101441.m7AEfInH019497@colwyn.zhadum.org.uk>
Date: Sun, 10 Aug 2008 15:41:18 +0100 (BST)
From: tron@zhadum.org.uk
Reply-To: tron@zhadum.org.uk
To: gnats-bugs@gnats.NetBSD.org
Subject: Accessing a null mounted process file system triggers a kernel panic
X-Send-Pr-Version: 3.95

>Number:         39335
>Category:       kern
>Synopsis:       Accessing a null mounted process file system triggers a kernel panic
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Aug 10 14:45:00 +0000 2008
>Originator:     Matthias Scheler
>Release:        NetBSD 4.0_STABLE (2008-07-01 sources)
>Organization:
Matthias Scheler                                  http://zhadum.org.uk/
>Environment:
System: NetBSD colwyn.zhadum.org.uk 4.0_STABLE NetBSD 4.0_STABLE (COLWYN) #0: Tue Jul 1 13:26:41 BST 2008 tron@colwyn.zhadum.org.uk:/src/sys/compile/COLWYN i386
Architecture: i386
Machine: i386
>Description:
I've got a script which creates a change root environment that I use for
building packages (e.g. for release engineering) work. The script uses
a combination of NFS and null mounts and copying of files.

When I tried to build the "mono" package inside that change root environment
the system crashed with a kernel panic:

panic: lockmgr: locking against myself
Begin traceback...
uvm_fault(0xea6f80fc, 0x10000, 1) -> 0xe
fatal page fault in supervisor mode
trap type 6 code 0 eip c037bec0 cs 8 eflags 10246 cr2 10002 ilevel 0
panic: trap
Faulted in mid-traceback; aborting...

Here is the stack trace I got from the crash dump:

#0  0xc037fb0b in cpu_reboot (howto=0, bootstr=0x0)
    at /usr/src/sys/arch/i386/i386/machdep.c:896
#1  0xc030e0e8 in panic (fmt=0xc04d0ee9 "trap")
    at /usr/src/sys/kern/subr_prf.c:246
#2  0xc03883ac in trap (frame=0xcdf1d674)
    at /usr/src/sys/arch/i386/i386/trap.c:339
#3  0xc010b087 in calltrap ()
#4  0xcdf10010 in ?? ()
#5  0x00000030 in ?? ()
#6  0xcdf10010 in ?? ()
#7  0xc01a0010 in pfioctl (dev=65538, cmd=4, addr=0x0, 
    flags=<value optimized out>, l=0x0)
    at /usr/src/sys/dist/pf/net/pf_ioctl.c:1636
#8  0xc01a76bd in db_get_value (addr=65538, size=4, is_signed=0)
    at /usr/src/sys/ddb/db_access.c:62
#9  0xc037c669 in db_stack_trace_print (addr=-839788588, have_addr=1, 
    count=65535, modif=0xc04c8d6f "", pr=0xc030df10 <printf>)
    at /usr/src/sys/arch/i386/i386/db_trace.c:447
#10 0xc030e0bf in panic (fmt=0xc04faf5c "lockmgr: locking against myself")
    at /usr/src/sys/kern/subr_prf.c:235
#11 0xc02ea3e1 in lockmgr (lkp=0x0, flags=65538, interlkp=0xd9fb3034)
    at /usr/src/sys/kern/kern_lock.c:768
#12 0xc03492dc in layer_lock (v=0xcdf1d860)
    at /usr/src/sys/miscfs/genfs/layer_vnops.c:626
#13 0xc0343f15 in VOP_LOCK (vp=0xd9fb3034, flags=65538)
    at /usr/src/sys/kern/vnode_if.c:1228
#14 0xc0340cf7 in vn_lock (vp=0xd9fb3034, flags=131074)
    at /usr/src/sys/kern/vfs_vnops.c:703
#15 0xc0333cde in getcwd_common (lvp=0xd9fb3034, rvp=0xd018fb08, 
    bpp=0xcdf1da18, bufp=0xc47ef400 "", limit=512, flags=0, l=0xce2f6df4)
    at /usr/src/sys/kern/vfs_getcwd.c:375
#16 0xc0225fd7 in procfs_readlink (v=0xcdf1dabc)
    at /usr/src/sys/miscfs/procfs/procfs_vnops.c:1476
#17 0xc034957c in layer_bypass (v=0xcdf1dabc)
    at /usr/src/sys/miscfs/genfs/layer_vnops.c:359
#18 0xc0343e5b in VOP_READLINK (vp=0xd41f4cd4, uio=0xcdf1db1c, cred=0xdb8b1864)
    at /usr/src/sys/kern/vnode_if.c:1098
#19 0xc0335e02 in namei (ndp=0xcdf1dbd8) at /usr/src/sys/kern/vfs_lookup.c:396
#20 0xc033c8f6 in sys___stat30 (l=0xce2f6df4, v=0xcdf1dc48, retval=0xcdf1dc68)
    at /usr/src/sys/kern/vfs_syscalls.c:2424
#21 0xc0387c39 in syscall_plain (frame=0xcdf1dc88)
    at /usr/src/sys/arch/i386/i386/syscall.c:144
#22 0xc0100623 in syscall1 ()
#23 0xcdf1dc88 in ?? ()
#24 0x0000001f in ?? ()
#25 0x0000001f in ?? ()
#26 0x0000001f in ?? ()
#27 0x0000001f in ?? ()
#28 0x00000004 in ?? ()
#29 0xbfbfd780 in ?? ()
#30 0xbfbfd3a8 in ?? ()
#31 0xbfbfd383 in ?? ()
#32 0xbfbfd383 in ?? ()
#33 0x0808b138 in ?? ()
#34 0x00000183 in ?? ()
#35 0x00000003 in ?? ()
#36 0x00000002 in ?? ()
#37 0xbbb8d6ab in ?? ()
#38 0x00000017 in ?? ()
#39 0x00000246 in ?? ()
#40 0xbfbfd29c in ?? ()
#41 0x0000001f in ?? ()

>How-To-Repeat:
1.) Mount "procfs" with "-o ro,linux" on "/proc".
2.) Create a change root environment which is good enough to build
    packages and use "mount_null" to "/proc" on "/path/to/chroot/proc".
3.) Run "make configure" in "pkgsrc/lang/mono".

>Fix:
I found an sufficient work around for my setup. When I directly mount
the process file system into the change root by a command like
"mount -t procfs -o ro procfs /path/to/chroot/proc" the kernel panic
isn't triggered.

I wonder however if this should either be fixed or at least prevented
by not allowing null mounts of a process file system.

Home	PR Database Search