NetBSD Problem Report #22725

Received: (qmail 9094 invoked by uid 605); 9 Sep 2003 01:09:31 -0000
Message-Id: <20030909010928.89FA811152@narn.netbsd.org>
Date: Tue,  9 Sep 2003 01:09:28 +0000 (UTC)
From: der.eremit@email.de
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: der.eremit@email.de
To: gnats-bugs@gnats.NetBSD.org
Subject: kernel panic while attempting mkfifo on NFS volume
X-Send-Pr-Version: www-1.0

>Number:         22725
>Category:       kern
>Synopsis:       kernel panic while attempting mkfifo on NFS volume
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Sep 09 01:10:00 +0000 2003
>Closed-Date:    
>Last-Modified:  Tue Apr 09 15:49:49 +0000 2013
>Originator:     Pascal Schmidt
>Release:        1.6.1
>Organization:
>Environment:
NetBSD neptune.local 1.6.1 NetBSD 1.6.1 (GENERIC) #0: Tue Apr  8 12:05:52 UTC 2003     autobuild@tgm.daemon.org:/autobuild/netbsd-1-6/i386/OBJ/autobuild/netbsd-1-6/src/sys/arch/i386/compile/GENERIC i386

>Description:
When attempting to run mkfifo on an NFS volume exported from a user-space NFS server on localhost, I get a protection fault inside the kernel.

output on the console (copied by hand) is:

kernel: protection fault trap, code=0
Stopped in pid 2075 (mkfifo) at memcpy+0x1a: repe movsl (%esi),%esi(%edi)

attempting to sync from the debugger does not work then:

db>sync
syncing disks... 7 done
panic: lockmgr: locking against myself
Stopped in pid 2075 (mkfifo) at cpu_Debugger+0x4: leave

Even if this is due to a bug in the NFS server, it should probably
not hang the kernel.

>How-To-Repeat:
1. make sure rpcbind is running, but in-kernel NFS server not
2. download http://www.tzi.de/~pharao90/crashme.tar.gz
3. zcat crashme.tar.gz | tar xf -
4. cd crashme
5. ./configure
6. make .depend
7. make
8. mkdir /tmp/test
9. mkdir /tmp/mnt
10. ./unfsd

now as root:

11. mount_nfs -3 127.0.0.1:/tmp/test /tmp/mnt
12. mkfifo /tmp/mnt/fifo

kernel trap immediately follows

>Fix:

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback
State-Changed-By: pooka@narn.netbsd.org
State-Changed-When: Sat, 19 Jan 2008 23:35:29 +0200
State-Changed-Why:
can you provide a stack backtrace?


State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 26 Oct 2008 23:12:15 +0000
State-Changed-Why:
Submitter's email is bouncing. Anyone else want to try to replicate this?


State-Changed-From-To: open->dead
State-Changed-By: hubertf@NetBSD.org
State-Changed-When: Sat, 20 Feb 2010 16:41:09 +0000
State-Changed-Why:
Feedback timeout.
If this still is a problem with a recent NetBSD version, please re-submit.

 - Hubert



State-Changed-From-To: dead->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 14 Mar 2010 18:34:39 +0000
State-Changed-Why:
Someone should really try to reproduce this. It is probably a bug in the
submitter's nfs server program, unfortunately (which is no longer available)
but it might not be -- either way, the nfs client should not crash just
because some nfs server does something screwy.


>Unformatted:
 I have a similar issue except I am not doing a mkfifo call, at least
 not explicitly.  This morning I mounted a NetBSD 5.1 amd64 machine on
 two different NetBSD 6.0.1 (GENERIC) amd64 machines.  The dmesg output
 can be viewed at the following URLs:

 http://www.vex.net/~darcy/dmesg.druid
 http://www.vex.net/~darcy/dmesg.lothlorien

 The systems are almost identical and yet this morning I was able to
 work on druid just fine but lothlorien rebooted twice within a very
 short time of starting to work on the remote FS.  In both cases I was
 running "pkg_rolling-replace -suv" using the mounted /usr/pkgsrc.

 These are production machines so I can't risk running NFS again.  I
 will have to work around it for now.  However, I can inspect anything
 on the systems if anyone needs more info.  If there is a real
 possibility of solving this I can possibly try something in the middle
 of the night some time but even then the system is in use.

Home	PR Database Search