Date: Sun, 17 Mar 2002 01:17:21 +0900 From: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> To: Poul-Henning Kamp <phk@freebsd.org> Cc: Hiten Pandya <hitmaster2k@yahoo.com>, Munehiro Matsuda <haro@h4.dion.ne.jp>, Robert Watson <rwatson@freebsd.org>, current@freebsd.org, smp@freebsd.org, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> Subject: Re: -current lock warning... Message-ID: <200203161618.g2GGHMA5085135@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> In-Reply-To: <200203161357.g2GDuwA5043113@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> References: <35758.1016270542@critter.freebsd.dk> <200203161357.g2GDuwA5043113@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
--Multipart_Sun_Mar_17_01:17:21_2002-1
Content-Type: text/plain; charset=US-ASCII
On Sat, 16 Mar 2002 22:56:58 +0900,
Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> said:
Seigo> On Sat, 16 Mar 2002 10:22:22 +0100,
Seigo> Poul-Henning Kamp <phk@freebsd.org> said:
Seigo> Poul-Henning> acquiring duplicate lock of same type: "thrd_sleep"
Seigo> Poul-Henning> 1st @ ../../../vm/vm_map.c:2288
Seigo> Poul-Henning> 2nd @ ../../../vm/vm_kern.c:172
Seigo> (snip)
Seigo> Poul-Henning> _vm_map_lock(c038afb4,c02f8440,ac,c034a840,1) at _vm_map_lock+0x16
Seigo> Poul-Henning> kmem_alloc(c038afb4,3000,c0e41a00,0,c02fa434) at kmem_alloc+0x41
Seigo> Poul-Henning> _zget(c0e41a00,bfc00000,0,c0435cd0,c0281769) at _zget+0xfa
Seigo> Poul-Henning> zalloc(c0e41a00,c034a840,1,c02f8630,a7) at zalloc+0x3b
Seigo> Poul-Henning> vmspace_alloc(0,bfc00000,c035c940,c02f8630,8f0) at vmspace_alloc+0x2d
Seigo> Poul-Henning> vmspace_fork(c035c940,cbb9ad24,c0331f84,cbb9ab00,c0331d60) at vmspace_fork+0x4d
Seigo> Poul-Henning> vm_forkproc(c0332080,cbb9ab00,cbb9ac00,20014) at vm_forkproc+0xc6
Seigo> This seems due to naming all of the vm map locks as "thrd_sleep." The
Seigo> locks of vm maps should have their own hierarachy. For instance, lock
Seigo> the map of a process vm space first, then lock the kernel_map.
The patch attached below renames the lock of the kernel_map to
"kernel_map" once witness gets ready to run. This eliminated all of
the lock order reversals on my PC.
--Multipart_Sun_Mar_17_01:17:21_2002-1
Content-Type: application/octet-stream; type=patch
Content-Disposition: attachment; filename="vm_map_renamelock.diff"
Content-Transfer-Encoding: 7bit
? i386/conf/BUNKO
? i386/conf/BUNKO.hints
? i386/conf/LINT
? modules/3dfx/pci.h
? modules/aha/aha.h
? modules/kernfs/kernfs.kld
? modules/kernfs/kernfs.ko
? modules/kernfs/setdef0.c
? modules/kernfs/setdef1.c
? modules/kernfs/setdefs.h
? modules/kernfs/vnode_if.h
? modules/lnc/lnc.kld
? modules/lnc/lnc.ko
? modules/random/opt_noblockrandom.h
? modules/svr4/opt_compat.h
? modules/svr4/opt_svr4.h
? modules/svr4/opt_vmpage.h
? modules/svr4/setdef0.c
? modules/svr4/setdef1.c
? modules/svr4/setdefs.h
? modules/svr4/svr4.kld
? modules/svr4/svr4.ko
? modules/svr4/svr4_assym.h
? modules/svr4/vnode_if.h
Index: vm/vm_kern.c
===================================================================
RCS file: /home/ncvs/src/sys/vm/vm_kern.c,v
retrieving revision 1.76
diff -u -r1.76 vm_kern.c
--- vm/vm_kern.c 10 Mar 2002 21:52:46 -0000 1.76
+++ vm/vm_kern.c 16 Mar 2002 15:48:29 -0000
@@ -515,3 +515,17 @@
/* ... and ending with the completion of the above `insert' */
vm_map_unlock(m);
}
+
+/*
+ * kernel_map_initialize:
+ *
+ * Rename the lock of kernel_map. We cannot do this in kmem_init
+ * because Witness is cold.
+ */
+static void
+kernel_map_initialize(void *dummy __unused)
+{
+ vm_map_renamelock(kernel_map, "kernel_map");
+}
+
+SYSINIT(kernel_map_init, SI_SUB_WITNESS, SI_ORDER_SECOND, kernel_map_initialize, NULL)
Index: vm/vm_map.c
===================================================================
RCS file: /home/ncvs/src/sys/vm/vm_map.c,v
retrieving revision 1.215
diff -u -r1.215 vm_map.c
--- vm/vm_map.c 13 Mar 2002 23:48:08 -0000 1.215
+++ vm/vm_map.c 16 Mar 2002 15:48:40 -0000
@@ -91,6 +91,9 @@
#include <vm/vm_zone.h>
#include <vm/swap_pager.h>
+/* The default name of a map lock. */
+#define MAPLOCK_NAME "vm map"
+
/*
* Virtual memory maps provide for the mapping, protection,
* and sharing of virtual memory objects. In addition,
@@ -405,7 +408,21 @@
map->first_free = &map->header;
map->hint = &map->header;
map->timestamp = 0;
- sx_init(&map->lock, "thrd_sleep");
+ sx_init(&map->lock, MAPLOCK_NAME);
+}
+
+/*
+ * vm_map_renamelock:
+ *
+ * Renames the lock of a VM map. This
+ * lets us check the lock order of VM
+ * maps.
+ */
+void
+vm_map_renamelock(vm_map_t map, const char *name)
+{
+ sx_destroy(&map->lock);
+ sx_init(&map->lock, name);
}
void
Index: vm/vm_map.h
===================================================================
RCS file: /home/ncvs/src/sys/vm/vm_map.h,v
retrieving revision 1.71
diff -u -r1.71 vm_map.h
--- vm/vm_map.h 13 Mar 2002 23:48:08 -0000 1.71
+++ vm/vm_map.h 16 Mar 2002 15:48:41 -0000
@@ -277,6 +277,7 @@
int vm_map_findspace (vm_map_t, vm_offset_t, vm_size_t, vm_offset_t *);
int vm_map_inherit (vm_map_t, vm_offset_t, vm_offset_t, vm_inherit_t);
void vm_map_init (struct vm_map *, vm_offset_t, vm_offset_t);
+void vm_map_renamelock (struct vm_map *, const char *);
void vm_map_destroy (struct vm_map *);
int vm_map_insert (vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t, vm_offset_t, vm_prot_t, vm_prot_t, int);
int vm_map_lookup (vm_map_t *, vm_offset_t, vm_prot_t, vm_map_entry_t *, vm_object_t *,
--Multipart_Sun_Mar_17_01:17:21_2002-1
Content-Type: text/plain; charset=US-ASCII
--
Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@FreeBSD.org>
--Multipart_Sun_Mar_17_01:17:21_2002-1--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203161618.g2GGHMA5085135>