From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 19:42:15 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 A104B106566B; Tue, 8 Sep 2009 19:42:15 +0000 (UTC) (envelope-from pluknet@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 D15408FC26; Tue, 8 Sep 2009 19:42:14 +0000 (UTC) Received: by fxm6 with SMTP id 6so2776705fxm.43 for ; Tue, 08 Sep 2009 12:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pTcygApz4GghzmsA50ty6FoAdXqyZkvfEt+FvpvFBv0=; b=vmEb0cvjKi3ZkqF6dz7UnezD4adLUW8XO8MYraMqQpVro6Lq1t9+zvjW3nJYLyU7SN FnGHBKnOv3aW3ZVi20sA2blftG09kZoI45suvLtXCWo3ZzsbPYCRkdJDtUDx0VrNdRtq yL1pCPm4gRnHssPj4wy4yJlUn4cfTK6XQKRAo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qU8Iz8Kk3xF1Y3/PAyBqBle1mS38iaSH/T/mrp1c6KXdgVYBng3pviwqe8LtENqzHG kM4eUOGfCetInDdF+P11IrUA/tRPqypGn19HXgpusqg/jjP55hP/dIAOxx5soIu63v8w 18HKBpLhRWU7/QKRfxyIzZQfMiaCTklYQfv7s= MIME-Version: 1.0 Received: by 10.204.25.152 with SMTP id z24mr13514406bkb.44.1252438933617; Tue, 08 Sep 2009 12:42:13 -0700 (PDT) In-Reply-To: <3bbf2fe10909080213i588493darf8dd1e1ff768cb0a@mail.gmail.com> References: <20090908091114.GH47688@deviant.kiev.zoral.com.ua> <3bbf2fe10909080213i588493darf8dd1e1ff768cb0a@mail.gmail.com> Date: Tue, 8 Sep 2009 23:42:13 +0400 Message-ID: From: pluknet To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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:42:15 -0000 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: >>> =A01st 0xc75365b8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_lookup.c:= 497 >>> =A02nd 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_loo= kup+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_o= pen+0x41 >>> syscall(e8214d38) at syscall+0x2b4 >>> Xint0x80_syscall() at Xint0x80_syscall+0x20 >>> --- syscall (5, Linux ELF, linux_open), eip =3D 0x2889115e, esp =3D >>> 0xbfbfbd1c, ebp =3D 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? --=20 wbr, pluknet