Date: Sun, 14 Dec 1997 21:30:01 -0800 (PST) From: "John S. Dyson" <dyson@FreeBSD.ORG> To: freebsd-bugs Subject: Re: kern/5298: zone allocator causes recursive lock on kernel_map Message-ID: <199712150530.VAA21150@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/5298; it has been noted by GNATS.
From: "John S. Dyson" <dyson@FreeBSD.ORG>
To: Tor.Egge@idi.ntnu.no
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/5298: zone allocator causes recursive lock on kernel_map
Date: Mon, 15 Dec 1997 00:21:27 -0500 (EST)
Tor Egge said:
>
> >Number: 5298
> >Category: kern
> >Synopsis: zone allocator causes recursive lock on kernel_map
> >Confidential: no
> >Severity: serious
> >Priority: medium
> >Responsible: freebsd-bugs
> >State: open
> >Class: sw-bug
> >Submitter-Id: current-users
> >Arrival-Date: Sun Dec 14 17:00:00 PST 1997
> >Last-Modified:
> >Originator: Tor Egge
> >Organization:
> Norwegian University of Science and Technology, Trondheim, Norway
> >Release: FreeBSD 3.0-CURRENT i386
> >Environment:
>
> FreeBSD ikke.idi.ntnu.no 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Mon Dec 15 00:52:02 MET 1997 root@ikke.idi.ntnu.no:/usr/src/sys/compile/TEGGE_SMP i386
>
>
> >Description:
>
> A call to kmem_free might cause a call to kmem_alloc that fails due to an
> exclusive lock on kernel_map already being held by the same process:
>
> panic: lockmgr: locking against myself
> mp_lock = 00000001; cpuid = 0; lapic.id = 01000000
>
> Current directory is /var/crash/
> GDB is free software and you are welcome to distribute copies of it
> under certain conditions; type "show copying" to see the conditions.
> There is absolutely no warranty for GDB; type "show warranty" for details.
> GDB 4.16 (i386-unknown-freebsd),
> Copyright 1996 Free Software Foundation, Inc...
> IdlePTD 2a2000
> current pcb at 239dbc
> panic: lockmgr: locking against myself
> #0 boot (howto=260) at ../../kern/kern_shutdown.c:285
> (kgdb) where
> #0 boot (howto=260) at ../../kern/kern_shutdown.c:285
> #1 0xe011bd6a in panic (fmt=0xe0101659 "from debugger")
> at ../../kern/kern_shutdown.c:425
> #2 0xe0101682 in db_panic (dummy1=-534958790, dummy2=0, dummy3=-1,
> dummy4=0xe80a5b94 "") at ../../ddb/db_command.c:440
> #3 0xe0101565 in db_command (last_cmdp=0xe0224ad4, cmd_table=0xe0224924,
> aux_cmd_tablep=0xe025a6bc) at ../../ddb/db_command.c:337
> #4 0xe01016fa in db_command_loop () at ../../ddb/db_command.c:462
> #5 0xe010407f in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
> #6 0xe01d2ab4 in kdb_trap (type=3, code=0, regs=0xe80a5c84)
> at ../../i386/i386/db_interface.c:157
> #7 0xe01e49f0 in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 281,
> tf_esi = 256, tf_ebp = -401974072, tf_isp = -401974100,
> tf_ebx = -535728897, tf_edx = -534958856, tf_ecx = 0, tf_eax = 18,
> tf_trapno = 3, tf_err = 0, tf_eip = -534958790, tf_cs = 8,
> tf_eflags = 598, tf_esp = -534958872, tf_ss = -535708485})
> at ../../i386/i386/trap.c:473
> #8 0xe01d2d3a in Debugger (msg=0xe011bcbb "panic")
> at ../../i386/i386/db_interface.c:316
> #9 0xe011bd61 in panic (fmt=0xe0116cff "lockmgr: locking against myself")
> at ../../kern/kern_shutdown.c:423
> #10 0xe0116f98 in lockmgr (lkp=0xe025a2e4, flags=2, interlkp=0x0, p=0xe1d53800)
> at ../../kern/kern_lock.c:288
> #11 0xe01c1316 in kmem_alloc (map=0xe025a2e0, size=4096)
> at ../../vm/vm_kern.c:149
> #12 0xe01cd12e in _zget (z=0xe0241204) at ../../vm/vm_zone.c:310
> #13 0xe01cd01e in zalloci (z=0xe0241204) at ../../vm/vm_zone.h:92
> #14 0xe01c5a1c in vm_object_allocate (type=OBJT_DEFAULT, size=2)
> at ../../vm/vm_object.c:229
> #15 0xe01c26d9 in _vm_map_clip_start (map=0xe025a2e0, entry=0xe9090cf0,
> start=3938254848) at ../../vm/vm_map.c:852
> #16 0xe01c39d2 in vm_map_delete (map=0xe025a2e0, start=3938254848,
> end=3938258944) at ../../vm/vm_map.c:1814
> #17 0xe01c3b8d in vm_map_remove (map=0xe025a2e0, start=3938254848,
> end=3938258944) at ../../vm/vm_map.c:1908
> #18 0xe01c145a in kmem_free (map=0xe025a2e0, addr=3938254848, size=4096)
> at ../../vm/vm_kern.c:213
> #19 0xe01492e2 in procfs_rwmem (curp=0xe1d53800, p=0xe1d53600, uio=0xe80a5f30)
> at ../../miscfs/procfs/procfs_mem.c:266
> #20 0xe0149380 in procfs_domem (curp=0xe1d53800, p=0xe1d53600, pfs=0xe1156060,
> uio=0xe80a5f30) at ../../miscfs/procfs/procfs_mem.c:305
> #21 0xe0149cb3 in procfs_rw (ap=0xe80a5eec)
> at ../../miscfs/procfs/procfs_subr.c:278
> #22 0xe0143279 in vn_read (fp=0xe1d4d080, uio=0xe80a5f30, cred=0xe1d57c80)
> at vnode_if.h:303
> #23 0xe0123bb7 in read (p=0xe1d53800, uap=0xe80a5f84)
> at ../../kern/sys_generic.c:121
> #24 0xe01e559b in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = -541072864,
> tf_esi = 224, tf_ebp = -541077416, tf_isp = -401973292, tf_ebx = 0,
> tf_edx = 0, tf_ecx = -541072864, tf_eax = 3, tf_trapno = 12, tf_err = 7,
> tf_eip = 155877, tf_cs = 31, tf_eflags = 663, tf_esp = -541078488,
> tf_ss = 39}) at ../../i386/i386/trap.c:997
> #25 0x260e5 in ?? ()
> #26 0x34ac in ?? ()
> #27 0x316b in ?? ()
> #28 0x107e in ?? ()
> [...]
> (kgdb) up 13
> #13 0xe01cd01e in zalloci (z=0xe0241204) at ../../vm/vm_zone.h:92
> (kgdb) print *z
> $8 = {zlock = {lock_data = 1}, zitems = 0xe0252cfc, zfreecnt = 32,
> zfreemin = 32, znalloc = 4526, zkva = 0, zpagecount = 0, zpagemax = 0,
> zmax = 0, ztotal = 544, zsize = 128, zalloc = 1, zflags = 16,
> zallocflag = 2, zobj = 0x0, zname = 0xe01c58d9 "VM OBJECT", znext = 0x0}
> (kgdb)
>
> >How-To-Repeat:
>
> Call ps many times during system startup, while the
> number of objects is increasing.
>
> >Fix:
>
> Detect that kernel_map is locked by the same process in _zget,
> and either temporarily allow recursion or act as if the ZONE_INTERRUPT
> flag is set on the zone
> >Audit-Trail:
> >Unformatted:
>
Committed a potential fix. Indeed the problem is as Tor Egge suggested.
The solution doesn't require usage of the ZONE_INTERRUPT mode or disabling
the recursive lock checks, but is done by using an alternate map when
needed. Unfortunately, the recursive lock check is probably a good idea
to keep the data structures consistant (especially as the code is
changed), and the ZONE_INTERRUPT mode requires a preallocation of VM
space, and that limits the size of the growth of the zone.
--
John
dyson@freebsd.org
jdyson@nc.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712150530.VAA21150>