From simon@optinet.com  Wed Feb 12 23:22:13 2003
Return-Path: <simon@optinet.com>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 9149D37B401
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 12 Feb 2003 23:22:13 -0800 (PST)
Received: from shark.acceleratedweb.net (shark-gw.acceleratedweb.net [207.99.79.39])
	by mx1.FreeBSD.org (Postfix) with SMTP id A3B1243FB1
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 12 Feb 2003 23:22:12 -0800 (PST)
	(envelope-from simon@optinet.com)
Received: (qmail 47217 invoked by uid 0); 13 Feb 2003 07:22:25 -0000
Message-Id: <20030213072218.47216.qmail@shark.acceleratedweb.net>
Date: 13 Feb 2003 07:22:18 -0000
From: simon@optinet.com
Reply-To: simon@optinet.com
To: FreeBSD-gnats-submit@freebsd.org
Cc: simon@optinet.com
Subject: Kernel disk quota related bug causes a panic when inode limits are set 
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         48234
>Category:       kern
>Synopsis:       Kernel disk quota related bug causes a panic when inode limits are set
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    das
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Feb 12 23:30:07 PST 2003
>Closed-Date:    Mon Mar 03 14:07:15 PST 2003
>Last-Modified:  Mon Mar 03 14:07:15 PST 2003
>Originator:     Simon <simon@optinet.com>
>Release:        FreeBSD 4.7-RELEASE i386
>Organization:
>Environment:
System: FreeBSD dhcp-731-1 4.7-RELEASE FreeBSD 4.7-RELEASE #0: Fri Feb 7 01:19:35 GMT 2003 root@dhcp-720-53:/usr/src/sys/compile/MANTIS i386


ServerWorks ServerSet III HE-SL chipset w/Dual P3 1.2Ghz CPU
2GB ECC SDRAM
Mylex AcceleRAID 170 w/seagate cheetah harddrives attached

>Description:
	FreeBSD panics when a lot of sub-directories and files within them are created one after another. 

Fatal trap 12: page fault while in kernel mode
mp_lock = 00000002; cpuid = 0; lapic.id = 00000000
fault virtual address = 0x0
fault code           = supervisor write, page not present
instruction pointer  = 0x8:0xc01cc212
stack pointer        = 0x10:0xf0207c08
frame pointer        = 0x10:0xf0207c58
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      = 275 (perl)
interrupt mask       = none <- SMP: XXX
trap number          = 12
panic: page fault
mp_lock = 00000002; cpuid = 0; lapic.id = 00000000
boot() called on cpu#0

#13 0xc0206549 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = -1078001617, tf_edi = 8, tf_esi = 
1209875424, 
      tf_ebp = -1077937732, tf_isp = -266305580, tf_ebx = 1209800268, tf_edx = 1209875424, tf_ecx = 16, 
      tf_eax = 5, tf_trapno = 7, tf_err = 2, tf_eip = 1209708800, tf_cs = 31, tf_eflags = 663, 
      tf_esp = -1077937776, tf_ss = 47}) at ../../i386/i386/trap.c:1175
1175            error = (*callp->sy_call)(p, args);
#12 0xc018f380 in open (p=0xe9417860, uap=0xf0207f80) at ../../kern/vfs_syscalls.c:1028
1028            error = vn_open(&nd, flags, cmode);
#11 0xc01931b0 in vn_open (ndp=0xf0207ec4, fmode=1538, cmode=420) at vnode_if.h:106
106             rc = VCALL(dvp, VOFFSET(vop_create), &a);
#10 0xc01cf7c9 in ufs_vnoperate (ap=0xf0207df8) at ../../ufs/ufs/ufs_vnops.c:2422
2422            return (VOCALL(ufs_vnodeop_p, ap->a_desc->vdesc_offset, ap));
#9  0xc01ccaa0 in ufs_create (ap=0xf0207df8) at ../../ufs/ufs/ufs_vnops.c:195
195             error =
#8  0xc01cf480 in ufs_makeinode (mode=33188, dvp=0xf0f1d940, vpp=0xf0207ed8, cnp=0xf0207eec)
    at ../../ufs/ufs/ufs_vnops.c:2167
2167            if ((error = getinoquota(ip)) ||
#7  0xc01cb5d2 in getinoquota (ip=0xce212000) at ../../ufs/ufs/ufs_quota.c:95
95              if (ip->i_dquot[USRQUOTA] == NODQUOT &&
#6  0xc01cc212 in dqget (vp=0xf0f1d700, id=1001, ump=0xcacbbc00, type=0, dqp=0xce212044)
    at ../../ufs/ufs/ufs_quota.c:763
763                             TAILQ_REMOVE(&dqfreelist, dq, dq_freelist);
#5  0xc0205a47 in trap (frame={tf_fs = -381616104, tf_es = 1744830480, tf_ds = 16, tf_edi = -276421056, 
      tf_esi = -890009540, tf_ebp = -266306472, tf_isp = -266306572, tf_ebx = -887662464, tf_edx = 0, 
      tf_ecx = -887736320, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -1071857134, tf_cs = 8, 
      tf_eflags = 66118, tf_esp = -836689920, tf_ss = -252586240}) at ../../i386/i386/trap.c:466
466                             (void) trap_pfault(&frame, FALSE, eva);
#4  0xc0205ea9 in trap_pfault (frame=0xf0207bc8, usermode=0, eva=0) at ../../i386/i386/trap.c:867
867                     trap_fatal(frame, eva);
#3  0xc0206218 in trap_fatal (frame=0xf0207bc8, eva=0) at ../../i386/i386/trap.c:974
974                     panic("%s", trap_msg[type]);

>How-To-Repeat:
	1. Make sure disk quotas are enabled
	2. Pick a system user and set its quota limits to 300,000 inodes and 3,000,000 blocks
	3. Switch to the user above, and using a script, create a sub-directory and few files
	containig about 17k of data each and one 1byte file within this sub-directory. Repeat
	this step using a different name for a sub-directory until the machine panics.

>Fix:

 	I noticed that disabling (setting soft/hard inode limit to 0) inode limits using edquota
	prevents the panic

>Release-Note:
>Audit-Trail:

From: David Schultz <dschultz@uclink.Berkeley.EDU>
To: simon@optinet.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/48234: Kernel disk quota related bug causes a panic when inode limits are set
Date: Wed, 19 Feb 2003 22:36:41 -0800

 Hmm...looks like a reference count overflow.  I will send you a
 small patch for testing as soon as I get a chance to verify that
 it works in -CURRENT.
State-Changed-From-To: open->patched 
State-Changed-By: das 
State-Changed-When: Mon Feb 24 00:58:03 PST 2003 
State-Changed-Why:  
Fixed in -CURRENT, awaiting MFC. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=48234 
Responsible-Changed-From-To: freebsd-bugs->das 
Responsible-Changed-By: das 
Responsible-Changed-When: Mon Feb 24 01:01:34 PST 2003 
Responsible-Changed-Why:  
Over to me. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=48234 

From: Dan Pelleg <daniel+bsd@pelleg.org>
To: freebsd-gnats-submit@FreeBSD.org, simon@optinet.com
Cc:  
Subject: kern/48234: Kernel disk quota related bug causes a panic when inode limits are set
Date: Tue, 25 Feb 2003 09:09:58 -0500

 I can reproduce this. I'm hoping it's the same problem as I reported in:
 http://docs.freebsd.org/cgi/getmsg.cgi?fetch=18741+0+current/freebsd-fs
 
 Note that there I assumed the problem was NFS-related. Now I'm not so sure
 that's the case: the script I wrote following simon's suggestion was run
 locally when it paniced the system.
State-Changed-From-To: patched->closed 
State-Changed-By: das 
State-Changed-When: Mon Mar 3 14:06:27 PST 2003 
State-Changed-Why:  
MFC'd last week. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=48234 
>Unformatted:
