On Sat, 16 Mar 2002 22:56:58 +0900, Seigo Tanimura <[EMAIL PROTECTED]> said:
Seigo> On Sat, 16 Mar 2002 10:22:22 +0100, Seigo> Poul-Henning Kamp <[EMAIL PROTECTED]> 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.
vm_map_renamelock.diff
Description: Binary data
-- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
