kmem leak in tmpmfs?

Arno J. Klaassen arno at
Thu May 25 09:01:46 PDT 2006


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

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

  8 rue des Haies
  F-75020 Paris, France

More information about the freebsd-stable mailing list