From owner-freebsd-stable@FreeBSD.ORG Thu May 25 16:01:41 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3319516A4CD for ; Thu, 25 May 2006 16:01:41 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A42E43D77 for ; Thu, 25 May 2006 16:01:33 +0000 (GMT) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.13.6/jtpda-5.4) with ESMTP id k4PG1W2w094095 for ; Thu, 25 May 2006 18:01:32 +0200 (CEST) X-Ids: 168 Received: from heho.labo (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id k4PG1Utl055879 for ; Thu, 25 May 2006 18:01:30 +0200 (MEST) Received: (from arno@localhost) by heho.labo (8.13.3/8.13.1/Submit) id k4PG1Upj055876; Thu, 25 May 2006 18:01:30 +0200 (MEST) (envelope-from arno) Sender: arno@heho.snv.jussieu.fr To: freebsd-stable@freebsd.org From: "Arno J. Klaassen" Date: 25 May 2006 18:01:30 +0200 Message-ID: Lines: 91 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (shiva.jussieu.fr [134.157.0.168]); Thu, 25 May 2006 18:01:32 +0200 (CEST) X-Virus-Scanned: ClamAV 0.88.2/1484/Thu May 25 17:19:23 2006 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at shiva.jussieu.fr with ID 4475D4DC.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Subject: kmem leak in tmpmfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2006 16:01:46 -0000 Hello, I get a very easy to reproduce panic on 6.1-STABLE : /etc/periodic/weekly/310.locate panics with panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated (kgdb) where #0 doadump () at pcpu.h:165 #1 0xc0577574 in boot (howto=260) at /files/bsd/src6/sys/kern/kern_shutdown.c:409 #2 0xc05778a6 in panic ( fmt=0xc078dc1d "kmem_malloc(%ld): kmem_map too small: %ld total allocated") at /files/bsd/src6/sys/kern/kern_shutdown.c:565 #3 0xc06df1ab in kmem_malloc (map=0xc10430c0, size=4096, flags=258) at /files/bsd/src6/sys/vm/vm_kern.c:299 #4 0xc06d49a7 in page_alloc (zone=0xc1035700, bytes=0, pflag=0x0, wait=0) at /files/bsd/src6/sys/vm/uma_core.c:958 #5 0xc06d43db in slab_zalloc (zone=0xc1035700, wait=258) at /files/bsd/src6/sys/vm/uma_core.c:823 #6 0xc06d60f6 in uma_zone_slab (zone=0xc1035700, flags=2) at /files/bsd/src6/sys/vm/uma_core.c:2025 #7 0xc06d635f in uma_zalloc_bucket (zone=0xc1035700, flags=2) at /files/bsd/src6/sys/vm/uma_core.c:2134 #8 0xc06d5f39 in uma_zalloc_arg (zone=0xc1035700, udata=0x0, flags=2) at /files/bsd/src6/sys/vm/uma_core.c:1942 #9 0xc05d17ff in cache_enter (dvp=0xc8bf1110, vp=0xc8dd4110, cnp=0xfe14bbbc) at uma.h:275 #10 0xc06c77c4 in ufs_lookup (ap=0xfe14ba40) at /files/bsd/src6/sys/ufs/ufs/ufs_lookup.c:583 #11 0xc0756073 in VOP_CACHEDLOOKUP_APV (vop=0x0, a=0x0) at vnode_if.c:150 #12 0xc05d1dfa in vfs_cache_lookup (ap=0x0) at vnode_if.h:82 #13 0xc0755fe8 in VOP_LOOKUP_APV (vop=0xc07c8a60, a=0xfe14baec) at vnode_if.c:99 #14 0xc05d71fb in lookup (ndp=0xfe14bb94) at vnode_if.h:56 #15 0xc05d6998 in namei (ndp=0xfe14bb94) at /files/bsd/src6/sys/kern/vfs_lookup.c:203 #16 0xc05e865f in kern_lstat (td=0xc6b29780, path=0x0, pathseg=UIO_USERSPACE, sbp=0x0) at /files/bsd/src6/sys/kern/vfs_syscalls.c:2125 #17 0xc05e85df in lstat (td=0x0, uap=0xfe14bd04) at /files/bsd/src6/sys/kern/vfs_syscalls.c:2109 #18 0xc073e672 in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 134664008, tf_esi = 134663936, tf_ebp = -1077941544, tf_isp = -32195228, tf_ebx = 672511016, tf_edx = 134663936, tf_ecx = 134561792, tf_eax = 190, tf_trapno = 0, tf_err = 2, tf_eip = 672396855, tf_cs = 51, tf_eflags = 582, tf_esp = -1077941700, tf_ss = 59}) at /files/bsd/src6/sys/i386/i386/trap.c:981 #19 0xc072b21f in Xint0x80_syscall () at /files/bsd/src6/sys/i386/i386/exception.s:200 #20 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) This box has nothing particular, apart from maybe a large number of stamp-file based test-databases (with a lot of zero-sized files named .key=value). Producing this bug is easy : - set tmpmfs="YES" and set tmpsize greater than around 220m - start /etc/periodic/weekly/310.locate (and nothing else!) - wait two-three hours and bang Last test is with tmpfs=1024m and I monitored df -h /tmp and vmstat -zm every minute; when the system panics, last output is : Filesystem Size Used Avail Capacity Mounted on /dev/md0 989M 219M 691M 24% /var/tmp vmstat -zm | fgrep md0 md0: 512, 0, 453257, 15, 453437 I'm quite not an expert, but looks to me as if md0 use stays almost 100% in kmem and is never swapped (as it is supposed to do by default according to the man-page). While here, and being struck as well by the nfsd-bug, at least vfs_lookup.c seems common to both problems. Full vmstat-zm logs available. Thanx, Arno -- Arno J. Klaassen SCITO S.A. 8 rue des Haies F-75020 Paris, France http://scito.com