NetBSD Problem Report #41158

From Manuel.Bouyer@lip6.fr  Mon Apr  6 10:16:27 2009
Return-Path: <Manuel.Bouyer@lip6.fr>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 53D3563B8A5
	for <gnats-bugs@gnats.NetBSD.org>; Mon,  6 Apr 2009 10:16:27 +0000 (UTC)
Message-Id: <200904061016.n36AGO1M001193@horn.soc.lip6.fr>
Date: Mon, 6 Apr 2009 12:16:24 +0200 (MEST)
From: Manuel Bouyer <Manuel.Bouyer@lip6.fr>
Reply-To: Manuel.Bouyer@lip6.fr
To: gnats-bugs@gnats.NetBSD.org
Subject: nfs_rename() locking against myself
X-Send-Pr-Version: 3.95

>Number:         41158
>Category:       kern
>Synopsis:       nfs_rename() locking against myself
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Apr 06 10:20:00 +0000 2009
>Closed-Date:    Wed Sep 02 14:40:38 +0000 2009
>Last-Modified:  Wed Sep 02 14:40:38 +0000 2009
>Originator:     Manuel Bouyer
>Release:        NetBSD 5.0_RC3
>Organization:
>Environment:
System: NetBSD horn 5.0_RC3 NetBSD 5.0_RC3 (DISCODEBUG) #34: Sun Apr 5 21:37:10 MEST 2009 bouyer@disco:/home/bouyer/src-5/src/sys/arch/i386/compile/DISCODEBUG i386
Architecture: i386
Machine: i386
>Description:
	A netbsd 5.0_RC3 NFS server with a DIAGNOSTIC+LOCKDEBUG kernel
	will occasionally panic with
Mutex error: lockdebug_wantlock: locking against myself

lock address : 0x00000000ce95a02c type     :     sleep/adaptive
initialized  : 0x00000000c03af442
shared holds :                  0 exclusive:                  1
shares wanted:                  0 exclusive:                  7
current cpu  :                  1 last held:                  0
current lwp  : 0x00000000cea49060 last held: 0x00000000cea49060
last locked  : 0x00000000c03b94b4 unlocked : 0x00000000c025f3c0
owner field  : 0x00000000cea49060 wait/spin:                1/0

Turnstile chain at 0xc071df60.
=> Turnstile at 0xcbf88068 (wrq=0xcbf88078, rdq=0xcbf88080).
=> 0 waiting readers:
=> 6 waiting writers: 0xcea59800 0xce4867a0 0xcea49ce0 0xcea17040 0xcea172c0 0
xcea17a40

panic: LOCKDEBUG
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip c03fb65c cs 8 eflags 246 cr2 cdc88000 ilevel 0
Stopped in pid 208.1 (nfsd) at  netbsd:breakpoint+0x4:  popl    %ebp
db{1}> tr
breakpoint(c0652a42,ce95d728,c2d08800,c03640cf,0,1,0,0,ce95d728,8) at netbsd:breakpoint+0x4
panic(c0652a44,c064e7f4,c0523e0f,c064e7c3,5748,1a49060,0,cf69cc44,0,ce95a02c) at netbsd:panic+0x1b0
lockdebug_abort1(c064e7c3,1,0,0,cbf6d508,cea49218,0,6,d35490ac,ce95db10) at netbsd:lockdebug_abort1+0xbb
mutex_vector_enter(ce95a02c,8,ce95db6c,c025e587,ce95a004,0,cec93000,ce8df000,c3b6a100,ce95db58) at netbsd:mutex_vector_enter+0x464
genfs_renamelock_enter(ce95a004,0,cec93000,ce8df000,c3b6a100,ce95db58,ce95db54,ce95db44,cea49060,0) at netbsd:genfs_renamelock_enter+0x14
nfsrv_rename(cec18e10,ce8df000,cea49060,ce95dbd0,cd137b00,c0713d58,0,c06aed18,c0713d58,0) at netbsd:nfsrv_rename+0x4b7
nfssvc_nfsd(ce95dc38,804a2e0,cea49060,0,0,0,0,0,0,ffffffff) at netbsd:nfssvc_nfsd+0x3d6
sys_nfssvc(cea49060,ce95dd00,ce95dd28,bfbff000,cea449f8,cea449f8,2,4,804a2e0,bfbfee94) at netbsd:sys_nfssvc+0x332
syscall(ce95dd48,b3,ab,bfbf001f,bbbd001f,6,1,bfbfee94,0,bfbffff0) at netbsd:syscall+0xc8

I have a core dump and netbsd.gdb if it helps

>How-To-Repeat:
	Run a LOCKDEBUG nfs server with a SMP linux client running
	build.sh -j16 and bonnie++
>Fix:

>Release-Note:

>Audit-Trail:
From: Andrew Doran <ad@netbsd.org>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/41158: nfs_rename() locking against myself
Date: Wed, 8 Apr 2009 19:38:12 +0000

 This is interesting:

 http://docs.freebsd.org/cgi/getmsg.cgi?fetch=544278+0+archive/1999/cvs-all/19990627.cvs-all

From: Andrew Doran <ad@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/41158: nfs_rename() locking against myself
Date: Wed, 8 Apr 2009 20:02:02 +0000

 On Wed, Apr 08, 2009 at 07:40:04PM +0000, Andrew Doran wrote:

 > From: Andrew Doran <ad@netbsd.org>
 > To: Manuel Bouyer <bouyer@antioche.eu.org>
 > Cc: gnats-bugs@netbsd.org
 > Subject: Re: kern/41158: nfs_rename() locking against myself
 > Date: Wed, 8 Apr 2009 19:38:12 +0000
 > 
 >  This is interesting:
 >  
 >  http://docs.freebsd.org/cgi/getmsg.cgi?fetch=544278+0+archive/1999/cvs-all/19990627.cvs-all

 If we add the 'goto nfsmout' we need the FreeBSD change to nfs_syscalls.c,
 to handle NFSERR_RETVOID. I'm looking at the rest of the changes but won't
 have time to go through them all tonight.

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/41158: nfs_rename() locking against myself
Date: Wed, 8 Apr 2009 22:28:50 +0200

 On Wed, Apr 08, 2009 at 08:05:03PM +0000, Andrew Doran wrote:
 >  >  This is interesting:
 >  >  
 >  >  http://docs.freebsd.org/cgi/getmsg.cgi?fetch=544278+0+archive/1999/cvs-all/19990627.cvs-all
 >  
 >  If we add the 'goto nfsmout' we need the FreeBSD change to nfs_syscalls.c,
 >  to handle NFSERR_RETVOID.

 I see that they're also using nfsm_srvdone in nfsrv_null() and nfsrv_noop()
 where I've keept the return(0). Is the nfs_syscalls.c change still needed
 in this case ?
 AFAIK is only matters for nfsrv_null() ...

 > I'm looking at the rest of the changes but won't
 >  have time to go through them all tonight.

 thanks

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: Andrew Doran <ad@netbsd.org>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/41158: nfs_rename() locking against myself
Date: Wed, 8 Apr 2009 20:34:39 +0000

 On Wed, Apr 08, 2009 at 10:28:50PM +0200, Manuel Bouyer wrote:
 > On Wed, Apr 08, 2009 at 08:05:03PM +0000, Andrew Doran wrote:
 > >  >  This is interesting:
 > >  >  
 > >  >  http://docs.freebsd.org/cgi/getmsg.cgi?fetch=544278+0+archive/1999/cvs-all/19990627.cvs-all
 > >  
 > >  If we add the 'goto nfsmout' we need the FreeBSD change to nfs_syscalls.c,
 > >  to handle NFSERR_RETVOID.
 > 
 > I see that they're also using nfsm_srvdone in nfsrv_null() and nfsrv_noop()
 > where I've keept the return(0). Is the nfs_syscalls.c change still needed
 > in this case ?
 > AFAIK is only matters for nfsrv_null() ...

 On having a second look I guess it does not matter.
 A mistake in their change?

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Andrew Doran <ad@netbsd.org>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/41158: nfs_rename() locking against myself
Date: Wed, 8 Apr 2009 22:38:02 +0200

 On Wed, Apr 08, 2009 at 08:34:39PM +0000, Andrew Doran wrote:
 > On Wed, Apr 08, 2009 at 10:28:50PM +0200, Manuel Bouyer wrote:
 > > On Wed, Apr 08, 2009 at 08:05:03PM +0000, Andrew Doran wrote:
 > > >  >  This is interesting:
 > > >  >  
 > > >  >  http://docs.freebsd.org/cgi/getmsg.cgi?fetch=544278+0+archive/1999/cvs-all/19990627.cvs-all
 > > >  
 > > >  If we add the 'goto nfsmout' we need the FreeBSD change to nfs_syscalls.c,
 > > >  to handle NFSERR_RETVOID.
 > > 
 > > I see that they're also using nfsm_srvdone in nfsrv_null() and nfsrv_noop()
 > > where I've keept the return(0). Is the nfs_syscalls.c change still needed
 > > in this case ?
 > > AFAIK is only matters for nfsrv_null() ...
 > 
 > On having a second look I guess it does not matter.
 > A mistake in their change?

 I don't think so, because their changes use nfsm_srvdone which does
 return(error) and not return(0) for nfsrv_null() and nfsrv_noop().
 But I don't see the point in returning error here (it's constant
 anyway).

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

State-Changed-From-To: open->closed
State-Changed-By: bouyer@NetBSD.org
State-Changed-When: Wed, 02 Sep 2009 14:40:38 +0000
State-Changed-Why:
Proposed patch commited (2009/04/10) and pulled up


>Unformatted:

Home	PR Database Search