Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Feb 2015 03:22:58 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        sbruno@freebsd.org
Cc:        freebsd-current@freebsd.org
Subject:   Re: panic on application core dump?
Message-ID:  <20150223012257.GO74514@kib.kiev.ua>
In-Reply-To: <54EA5F89.1010102@ignoranthack.me>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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 ?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150223012257.GO74514>