LOR: kern_descrip.c:2277,2278
Roman Kurakin
rik at cronyx.ru
Mon Oct 3 12:22:05 PDT 2005
Hi,
John Baldwin:
>On Monday 03 October 2005 04:10 am, Roman Kurakin wrote:
>
>
>>Hi,
>>
>>Could you check:
>>
>>http://lists.freebsd.org/pipermail/freebsd-current/2005-September/056078.ht
>>ml
>>
>>Best regards,
>> rik
>>
>>
>
>If it doesn't trigger any other LORs then it is probably fine.
>
It is applied on my development machine and I didn't see any
other LOR. I'll commit it to current, and probably it wouldn't
be a good idea to MFC it before 6.0.
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) @
>>>>sys/kern/kern_descrip.c:2277 2nd 0xffffff00222d8a48 filedesc structure
>>>>(filedesc structure) @ 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.
>>>
>>>
>
>
>
More information about the freebsd-current
mailing list