Hi, Could you check: http://lists.freebsd.org/pipermail/freebsd-current/2005-September/056078.html Best regards, rik John Baldwin wrote: >On Monday 17 January 2005 05:07 pm, Bjoern A. Zeeb wrote: > > >>Hi, >> >>I have added the following as LOR #055 to "the LOR page"[1]. >> >>lock order reversal >> 1st 0xffffffff80c3a9e8 sleep mtxpool (sleep mtxpool) _at_ >>sys/kern/kern_descrip.c:2277 2nd 0xffffff00222d8a48 filedesc structure >>(filedesc structure) _at_ sys/kern/kern_descrip.c:2278 KDB: stack backtrace: >>witness_checkorder() at witness_checkorder+0x5f1 >>_mtx_lock_flags() at _mtx_lock_flags+0x4a >>dupfdopen() at dupfdopen+0x320 >>kern_open() at kern_open+0x5de >>syscall() at syscall+0x4ab >>Xfast_syscall() at Xfast_syscall+0xa8 >>--- syscall (5, FreeBSD ELF64, open), rip = 0x80077e7d0, rsp = >>0x7fffffffe6f8, rbp = 0x7fffffffec70 --- >> >>I can easily reproduce it every boot. It seems to be triggered by >>Capi4BSD[2] framework which I incorporated in my private tree. >> >>Can someone please comment on this ? >> >> > >The problem is that FILEDESC_UNLOCK() actually includes an entirely separate >lock of its own (it's like an sx lock sort of). One possible fix might be to >change struct file to either use a dedicated mutex pool (instead of the more >generic mtxpool_sleep one that is intended only for leaf-lock usage) or to >have each struct file include its own mutex rather than using a pool lock. > >Received on Mon Oct 03 2005 - 06:16:00 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:44 UTC