From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 19:48:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E84991065670; Tue, 8 Sep 2009 19:48:38 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id 4C44E8FC17; Tue, 8 Sep 2009 19:48:38 +0000 (UTC) Received: by fxm6 with SMTP id 6so2780548fxm.43 for ; Tue, 08 Sep 2009 12:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=FxF6iyIz3Yaxlr/2a9JYNeD4/t7osvL4m2UChl8R1Zo=; b=lMjqDNz0TPHMpevZ9wm+bMnRhVAGLs4LWoi53IrBpch/DAOaJAVcmC/IN8TfRYmOsO 5TGiDizRI0nXeHoj+ucgtLG0es+NpJTSoCcNjGeutIke3t1PViq0EBD0SxDld93GFR8G PfLpzhUE++hbK4YCvRzrBedqh0SLE1VVK7XDU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=JeapOVkfzynClegJqSCCfcM5bU/fXxqDu4gg3JU0v0rbEcPoR8vZXyl9xHXLG9ulH5 yc93lK8/ajVPx3a9OnfUzkJoSVE6lMM5bQqPvSB+6WCpaOI8tJzDReETZV1QrvHPGzzI WOg5z2CctnJwrPrpt/KWQCu+f5WYVbKeMH4Cw= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.58.139 with SMTP id g11mr6185875fah.43.1252439317464; Tue, 08 Sep 2009 12:48:37 -0700 (PDT) In-Reply-To: References: <20090908091114.GH47688@deviant.kiev.zoral.com.ua> <3bbf2fe10909080213i588493darf8dd1e1ff768cb0a@mail.gmail.com> Date: Tue, 8 Sep 2009 21:48:37 +0200 X-Google-Sender-Auth: 810d6bb753d3e452 Message-ID: <3bbf2fe10909081248w3a09c9a8ge3b6fa9de8b2d3e9@mail.gmail.com> From: Attilio Rao To: pluknet Content-Type: text/plain; charset=UTF-8 Cc: Kostik Belousov , freebsd-emulation@freebsd.org, FreeBSD Current Subject: Re: acquiring duplicate lock of same type: "ftlk" 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, 08 Sep 2009 19:48:39 -0000 2009/9/8 pluknet : > 2009/9/8 Attilio Rao : >> 2009/9/8 Kostik Belousov : >>> On Mon, Sep 07, 2009 at 10:15:48PM +0400, pluknet wrote: >>>> lock order reversal: >>>> 1st 0xc75365b8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_lookup.c:497 >>>> 2nd 0xc088ea3c allproc (allproc) @ /usr/src/sys/kern/kern_proc.c:292 >>>> KDB: stack backtrace: >>>> db_trace_self_wrapper(c07fd8ea,e82148e4,c060a145,c05fac1b,c08008bf,...) >>>> at db_trace_self_wrapper+0x26 >>>> kdb_backtrace(c05fac1b,c08008bf,c58eabe8,c58e30d0,e8214940,...) at >>>> kdb_backtrace+0x29 >>>> _witness_debugger(c08008bf,c088ea3c,c07f981d,c58e30d0,c07f96f0,...) at >>>> _witness_debugger+0x25 >>>> witness_checkorder(c088ea3c,1,c07f96f0,124,0,...) at witness_checkorder+0x839 >>>> _sx_slock(c088ea3c,0,c07f96f0,124,c73c4980,...) at _sx_slock+0x85 >>>> pfind(514,c72ba1a0,4,c07f8d78,c5fe1b40,...) at pfind+0x2f >>>> pfs_visible(0,0,c07f042d,7c,c7536560,...) at pfs_visible+0x3a >>>> pfs_lookup(e8214a40,c082715e,c7536560,c7536560,e8214bf8,...) at pfs_lookup+0x3dd >>>> VOP_CACHEDLOOKUP_APV(c0843960,e8214a40,e8214bf8,e8214be4,c73c4e80,...) >>>> at VOP_CACHEDLOOKUP_APV+0xc5 >>>> vfs_cache_lookup(e8214acc,c08087d0,c0875a00,200000,e8214bcc,...) at >>>> vfs_cache_lookup+0xd6 >>>> VOP_LOOKUP_APV(c0843960,e8214acc,e8214bf8,1f1,e8214be4,...) at >>>> VOP_LOOKUP_APV+0xe5 >>>> lookup(e8214bcc,c5fd1800,0,c5,c5ef77f8,...) at lookup+0x63b >>>> namei(e8214bcc,c5c1500d,3f3,e8214c20,c5c1500d,...) at namei+0x57f >>>> kern_alternate_path(c5fe1b40,c0b4921c,2879f478,0,e8214c74,...) at kern_alternate >>>> _path+0x1cd >>>> linux_emul_convpath(c5fe1b40,2879f478,0,e8214c74,0,...) at >>>> linux_emul_convpath+0x3c >>>> linux_open(c5fe1b40,e8214cf8,e8214d18,e8214d1c,c0b4b58c,...) at linux_open+0x41 >>>> syscall(e8214d38) at syscall+0x2b4 >>>> Xint0x80_syscall() at Xint0x80_syscall+0x20 >>>> --- syscall (5, Linux ELF, linux_open), eip = 0x2889115e, esp = >>>> 0xbfbfbd1c, ebp = 0xbfbfbd6c --- >>>> acquiring duplicate lock of same type: "ftlk" >>>> [...] >>> >>> The second LOR actually exposes the right order. It would be interesting >>> to look up the point where the other order is established. >> >> You would manually patch the witness static table with this order and >> the opposite will show, when happening. >> > > I've patched witness order table, and still no opposite case, > nor any pseudofs related LORs at all. > { "pseudofs", &lock_class_lockmgr }, > { "allproc", &lock_class_sx }, > { NULL, NULL }, > > Seen orders with pseudofs: > "ufs","pseudofs" > "pseudofs","allproc" > "pseudofs","process lock" > "pseudofs","vnode interlock" > "pseudofs","struct mount mtx" > "pseudofs","UMA zone" > "pseudofs","sleep mtxpool" > "pseudofs","Name Cache" > "pseudofs","vnode_free_list" > "pseudofs","pfs_node" > "pseudofs","pfs_vncache" > > Something else? Probabilly it just takes time. You should try to recreate conditions you did before to get this LOR. Attilio -- Peace can only be achieved by understanding - A. Einstein