Re: LOR: kern_descrip.c:2277,2278

From: John Baldwin <jhb_at_FreeBSD.org>
Date: Mon, 3 Oct 2005 13:06:29 -0400
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.

> 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.

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
Received on Mon Oct 03 2005 - 15:07:01 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:44 UTC