Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 Mar 1996 13:20:40 -0800 (PST)
From:      kls@ohare.chicago.com (Karl Swartz)
To:        bugs@freebsd.org
Subject:   execution from null fs panics system
Message-ID:  <m0tuQdU-0000FbC@ohare.chicago.com>

next in thread | raw e-mail | index | archive | help
I submitted the attach gnats report on Sunday but haven't heard
anything back yet, not even an ack, so I'm not sure if it made it or
not.  I've also got some additional information.

The original report described a panic while executing a shell script
created in a null filesystem mounted over a sub-tree of /usr.  It now
appears that the system panics when executing *anything* from out of
a null fs, not just scripts.  I've generated a few crash dumps and
found that in some cases the panic is an integer divide fault while
in others it is the orignally reported kernel page fault.  It seems
to depend on the specific kernel.

Here's a stack trace from one of the kernel page faults:

    IdlePTD 20b000
    current pcb at 1fbb10
    panic: page fault
    #0  0xf0198a01 in boot ()
    (kgdb) bt
    #0  0xf0198a01 in boot ()
    #1  0xf0112aa3 in panic ()
    #2  0xf01a07ee in trap_fatal ()
    #3  0xf01a0360 in trap_pfault ()
    #4  0xf019ffff in trap ()
    #5  0xf019621d in calltrap ()
    #6  0xf05ee6fc in end ()
    #7  0xf019469b in vnode_pager_haspage ()
    #8  0xf0193ac4 in vm_pager_has_page ()
    #9  0xf018b128 in vm_fault_additional_pages ()
    #10 0xf018a226 in vm_fault ()
    #11 0xf01a0316 in trap_pfault ()
    #12 0xf019ffff in trap ()
    #13 0xf019621d in calltrap ()
    #14 0xf0104177 in exec_aout_imgact ()
    #15 0xf0108cd2 in execve ()
    #16 0xf01a09cf in syscall ()
    #17 0xf019626b in Xsyscall ()

The one for an integer divide fault craps out at roughly the same
place:

    IdlePTD 1a2000
    current pcb at 1975b8
    panic: integer divide fault
    #0  0xf015f72d in boot ()
    (kgdb) bt
    #0  0xf015f72d in boot ()
    #1  0xf010eed3 in panic ()
    #2  0xf01645be in trap_fatal ()
    #3  0xf0163e7e in trap ()
    #4  0xf015d05d in calltrap ()
    #5  0xf015b75f in vnode_pager_haspage ()
    #6  0xf015abd4 in vm_pager_has_page ()
    #7  0xf0152238 in vm_fault_additional_pages ()
    #8  0xf0151336 in vm_fault ()
    #9  0xf01640e6 in trap_pfault ()
    #10 0xf0163dcf in trap ()
    #11 0xf015d05d in calltrap ()
    #12 0xf0100587 in exec_aout_imgact ()
    #13 0xf01050c2 in execve ()
    #14 0xf016479f in syscall ()
    #15 0xf015d0ab in Xsyscall ()

In both cases, I was trying to run a shell script, not an a.out file
(though an a.out produces a similar panic).  That doesn't leave much
suspect code in exec_aout_imgact(), so it seems that it has probably
received a bogus reference to vm space from execve().  Within that
routine, the VOP_UNLOCK() call or something in exec_check_perissions()
seems to be the likely culprit.  I followed VOP_UNLOCK() down into
the null fs code a bit, but haven't gotten very far yet.

 -- Karl

*** gnats report ***

>Submitter-Id:   current-users
>Originator:     Karl Swartz
>Organization:   Karl Swartz	|Home	kls@chicago.com
		|Work	kls@slac.stanford.edu
		|WWW	http://www.chicago.com/~kls/
Moderator of sci.aeronautics.airliners -- Unix/network work pays the bills
>Confidential:   no
>Synopsis:       null fs panics system
>Severity:       critical
>Priority:       medium
>Category:       kern
>Release:        FreeBSD 2.1-STABLE i386
>Class:          sw-bug
>Environment: 

Newly installed FreeBSD 2.1 system (from Walnut Creek CDROM), with
selected packages installed (including bash and perl) but no other
special software, running the stock kernel on the following hardware:

    Alaris motherboard with IBM 486SLC2-66 (no 387 installed)
    8 MB memory
    generic IDE controller
    Maxtor 7420AV disk
    SMC Ultra Ethernet

User home directories in /usr/u/<user>, which preferably would be
visible as /u/<user> via a null/lofs mount.

Running as nonprivileged user with bash as the default shell.

>Description: 

The system panics as follows when trying to execute a newly created
Perl script iff running from a null fs:

    Fatal trap 12: page fault while in kernel mode
    fault virtual address   = 0x0
    fault code              = supervisor read, page not present
    instruction pointer     = 0x8:0xf05586fc
    code segment            = base 0x0, limit 0xfffff, type 0x1b
                            = DPL 0, pres 1, def32 1, gran 1
    processor eflags        = interrupt enabled, resume, IOPL = 0
    current process         = 1119 (bash)
    interrupt mask          =
    panic: page fault

>How-To-Repeat: 

(login)
$ echo $SHELL
/usr/local/bin/bash
$ echo $HOME
/usr/u/user
$ su
Password:
# mkdir /u
# mount -t null /usr/u /u
# exit
$ cd /u/user
$ mkdir panic
$ cd panic
$ cat >hello <<EOF
#!/usr/local/bin/perl
print "Hello, world!!!\n";
EOF
$ chmod a+x hello
$ ./hello

Panic occurs at this point immediately and consistently.  I'm not sure
if the extra directory or creating the script via the null fs matters
or not.  Running the script again after rebooting will again panic the
system.  Doing the same with a symlink from /u to /usr/u, or running
the script in /usr/u/panic, will not panic the system.  I have not
tried to see if the problem is specific to bash as the shell and/or
perl scripts.

>Fix: 
	
	





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0tuQdU-0000FbC>