Re: kern/42205: kernel panic at activated userquota

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

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
--