Date: 13 Feb 2003 07:22:18 -0000 From: simon@optinet.com To: FreeBSD-gnats-submit@FreeBSD.org Cc: simon@optinet.com Subject: kern/48234: Kernel disk quota related bug causes a panic when inode limits are set Message-ID: <20030213072218.47216.qmail@shark.acceleratedweb.net>
next in thread | raw e-mail | index | archive | help
>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: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Feb 12 23:30:07 PST 2003 >Closed-Date: >Last-Modified: >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: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030213072218.47216.qmail>