Re: kern/42205: kernel panic at activated userquota

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

The following reply was made to PR kern/42205; it has been noted by GNATS.

From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: kern-bug-people%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost, 
netbsd-bugs%NetBSD.org@localhost
Subject: Re: kern/42205: kernel panic  at activated userquota
Date: Tue, 20 Oct 2009 21:39:02 +0200

 On Tue, Oct 20, 2009 at 04:10:00PM +0000, 
6bone%6bone.informatik.uni-leipzig.de@localhost wrote:
 > >Number:         42205
 > >Category:       kern
 > >Synopsis:       kernel panic  at activated userquota
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       high
 > >Responsible:    kern-bug-people
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Tue Oct 20 16:10:00 +0000 2009
 > >Originator:     Uwe Toenjes
 > >Release:        NetBSD 5.0_STABLE
 > >Organization:
 > University of Leipzig
 > >Environment:
 > NetBSD 6bone.informatik.uni-leipzig.de 5.0_STABLE NetBSD 5.0_STABLE (MYCONF) 
 > #0: Fri Oct 16 11:16:05 CEST 2009  
 > root%6bone.informatik.uni-leipzig.de@localhost:/usr/obj/sys/arch/amd64/compile/MYCONF
 >  amd64
 > >Description:
 > at high i/o a kernel panic can occur if you are using quota. without 
 > userquota everything works fine.
 > 
 > uvm_fault(0xffffffff80c79620, 0x0, 1) -> e                                   
 >    
 > fatal page fault in supervisor mode                                          
 >    
 > trap type 6 code 0 rip ffffffff803e46b3 cs 8 rflags 10246 cr2  70 cpl 0 rsp 
 > fff0
 > kernel: page fault trap, code=0                                              
 >    
 > Stopped in pid 0.61 (system) at netbsd:qsync+0x103:     movq    
 > 0x70(%rdx,%rax,8
 > ),%r14                                                                       
 >    
 > db{0}> trace                                                                 
 >    
 > qsync() at netbsd:qsync+0x103                                                
 >    
 > ffs_sync() at netbsd:ffs_sync+0x2eb                                          
 >    
 
 This seems to be:
 0xffffffff8025d7c3 is in qsync 
(/dsk/l1/misc/bouyer/netbsd-5/src/sys/ufs/ufs/ufs_quota.c:747).
 742                                     goto again;
 743                             }
 744                             continue;
 745                     }
 746                     for (i = 0; i < MAXQUOTAS; i++) {
 747                             dq = VTOI(vp)->i_dquot[i];
 
 (gdb) print &((struct inode *)0)->i_dquot[0]
 $1 = (struct dquot **) 0x70
 
 Another case where a vnode could be vlean'ed while vget drops the
 interlock to before getting the vn_lock.
 The attached patch may help, but it's untested and probably not the
 right way of fixing this.
 
 Any idea how to properly fix vget() anyone ?
 
 -- 
 Manuel Bouyer <bouyer%antioche.eu.org@localhost>
      NetBSD: 26 ans d'experience feront toujours la difference
 --