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>