I believe that the attached commit addresses the "panic: sleeping thread owns a mutex" problem reported by Kris and another related problem reported a few days earlier. The earlier problem report included the following stack trace: Sleeping on "objtrm" with the following non-sleepablelocks held: exclusive sleep mutex system map r = 0 (0xfffff80067e92098) locked _at_ /usr/src/sys/vm/vm_map.c:2192 lock order reversal 1st 0xfffff80067e92098 system map (system map) _at_ /usr/src/sys/vm/vm_map.c:2192 2nd 0xc0354d70 Giant (Giant) _at_ /usr/src/sys/kern/kern_synch.c:312 Stack backtrace: _mtx_lock_flags() at _mtx_lock_flags+0xa0 msleep() at msleep+0x6a8 vm_object_pip_wait() at vm_object_pip_wait+0x48 vm_object_terminate() at vm_object_terminate+0x30 vm_object_deallocate() at vm_object_deallocate+0x374 vm_map_entry_delete() at vm_map_entry_delete+0x3c vm_map_delete() at vm_map_delete+0x32c vm_map_remove() at vm_map_remove+0x44 kmem_free() at kmem_free+0x20 pipe_free_kmem() at pipe_free_kmem+0x98 pipeclose() at pipeclose+0x124 pipe_close() at pipe_close+0x20 fdrop_locked() at fdrop_locked+0x134 fdrop() at fdrop+0x20 closef() at closef+0x1f8 close() at close+0x168 syscall() at syscall+0x2ac -- syscall (6, FreeBSD ELF64, close) %o7=0x10706c --
attached mail follows:
alc 2003/07/30 11:55:04 PDT FreeBSD src repository Modified files: sys/kern sys_pipe.c Log: The introduction of vm object locking has caused witness to reveal a long-standing mistake in the way a portion of a pipe's KVA is allocated. Specifically, kmem_alloc_pageable() is inappropriate for use in the "direct" case because it allows a preceding vm map entry and vm object to be extended to support the new KVA allocation. However, the direct case KVA allocation should not have a backing vm object. This is corrected by using kmem_alloc_nofault(). Submitted by: tegge (with the above explanation by me) Revision Changes Path 1.140 +1 -1 src/sys/kern/sys_pipe.cReceived on Wed Jul 30 2003 - 19:15:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:17 UTC