From owner-freebsd-current@FreeBSD.ORG Tue Oct 4 19:55:13 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C323A16A421 for ; Tue, 4 Oct 2005 19:55:13 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id F032D43D45 for ; Tue, 4 Oct 2005 19:55:12 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru (8.13.0/vak/3.0) id j94Jq8qF072746 for current@FreeBSD.org.checked; Tue, 4 Oct 2005 23:52:08 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (localhost.cronyx.ru [127.0.0.1]) by hanoi.cronyx.ru (8.13.0/vak/3.0) with ESMTP id j94JpG07072705; Tue, 4 Oct 2005 23:51:16 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <4342DB05.10608@cronyx.ru> Date: Tue, 04 Oct 2005 23:41:57 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030426 X-Accept-Language: ru-ru, en MIME-Version: 1.0 To: John Baldwin References: <200501181124.19323.jhb@FreeBSD.org> <4340E785.3030705@cronyx.ru> <200510031306.31314.jhb@FreeBSD.org> In-Reply-To: <200510031306.31314.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: LOR: kern_descrip.c:2277,2278 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2005 19:55:13 -0000 Commited. rik 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. > > > >>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. >>> >>> > > >