From owner-freebsd-current@FreeBSD.ORG Mon Feb 23 01:23:07 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECF07C13; Mon, 23 Feb 2015 01:23:07 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E2B4250; Mon, 23 Feb 2015 01:23:07 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t1N1Mwep045386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2015 03:22:58 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t1N1Mwep045386 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t1N1Mwni045385; Mon, 23 Feb 2015 03:22:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 23 Feb 2015 03:22:58 +0200 From: Konstantin Belousov To: sbruno@freebsd.org Subject: Re: panic on application core dump? Message-ID: <20150223012257.GO74514@kib.kiev.ua> References: <54E8EA2A.7020904@ignoranthack.me> <20150221211712.GG74514@kib.kiev.ua> <54EA1325.6070009@ignoranthack.me> <20150222180425.GJ74514@kib.kiev.ua> <54EA241D.6020606@ignoranthack.me> <20150222185352.GL74514@kib.kiev.ua> <54EA25FE.60401@ignoranthack.me> <54EA5F89.1010102@ignoranthack.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54EA5F89.1010102@ignoranthack.me> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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: Mon, 23 Feb 2015 01:23:08 -0000 On Sun, Feb 22, 2015 at 03:00:25PM -0800, Sean Bruno wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 02/22/15 10:54, Sean Bruno wrote: > > On 02/22/15 10:53, Konstantin Belousov wrote: > >> On Sun, Feb 22, 2015 at 10:46:53AM -0800, Sean Bruno wrote: > >>> Hmm ... looks unrelated to signals (maybe). This looks like a > >>> common ZFS deadlock that is yet undiagnosed. I do not have a > >>> show alllocks command available in db> . I will show each > >>> lock information below: > >> Add witness. > > > >>> > >>> db> show lockedvnods Locked vnodes > >>> > >>> 0xfffff801141a6588: tag zfs, type VDIR usecount 19, writecount > >>> 0, refcount 20 mountedhere 0 flags (VV_ROOT|VI_ACTIVE) > >>> v_object 0xfffff80079be4500 ref 0 pages 0 cleanbuf 0 dirtybuf 0 > >>> lock type zfs: EXCL by thread 0xfffff801ca10c4a0 (pid 75907, > >>> sh, tid 101262) with exclusive waiters pending > >> Without backtraces of the acquisition, it is not useful. You > >> need DEBUG_VFS_LOCKS for this. > > > > > > > > Thank you. I will do so and restart my non-determinstic test and > > see what I can find. > > > > sean _______________________ > > Well, that was certainly enlightening. I was able to get a WITNESS > panic in imgact_binmisc.c in an hour or two. I need to *not* hold the > mtx protecting the list of activators over the bcopy in > imgact_binmisc_exec(). > > Jiles proposes that we switch to an sx lock here for simplicity of > change of the code. > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex imgact_binmisc (imgact_binmisc) r = 0 > (0xffffffff82012418) locked @ > /usr/src/sys/modules/imgact_binmisc/../../kern/imgact_binmisc.c:596 So was it the reason for your troubles after the patch for handling core file' vnode refcount properly ? Or is there something more left ?