From owner-freebsd-stable@FreeBSD.ORG Wed Dec 25 05:42:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19F955AB for ; Wed, 25 Dec 2013 05:42:28 +0000 (UTC) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB7FC1359 for ; Wed, 25 Dec 2013 05:42:27 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id g10so6949856pdj.29 for ; Tue, 24 Dec 2013 21:42:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=3IMlZfqWIqRXdThZ2urJapBQSL7YdK03LtNZrGkpd6A=; b=oKxYbbSX+bD1Lod0Itqsd17OrVBDrk/03rweqcdda3mhr12c9N/U07ciu6u6k10ZFr imeS/er7KyDDwKlkCUkk2s4evHCh4s5u7Q6/EogWOzyVxGR+kOhEVo6mnO+ax246YKAU n3e7jnlfEXHBV+IWVSzpaS4Z5Hi2Q5eN65b5Lb9a4TU248CTELsXtdLkizh33WEgLFw/ Jq2XsNFtoowVEjpUhjpF33S4m3A8c1X+0rfW+zlu+vwrafVUVQzYMUqLtsJ+94xekfWO H1cIg86+EVwUetJxlu8iUx86hZjo1IMK3IQKg5t5vRgTzHMIZOdZDUWFgj9UDgBW+SSE 717g== X-Received: by 10.66.180.200 with SMTP id dq8mr36650924pac.104.1387950147552; Tue, 24 Dec 2013 21:42:27 -0800 (PST) Received: from localhost (c-76-21-78-151.hsd1.ca.comcast.net. [76.21.78.151]) by mx.google.com with ESMTPSA id uf2sm45728083pbc.28.2013.12.24.21.42.25 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Dec 2013 21:42:26 -0800 (PST) Date: Tue, 24 Dec 2013 21:42:27 -0800 From: Gleb Kurtsou To: Konstantin Belousov Subject: Re: 9.2-RELEASE amd64 panic: vn_open_cred Message-ID: <20131225054227.GA2691@reks> References: <20131106022932.GY59496@kib.kiev.ua> <57A9579D-7BA6-4ED8-9EE0-D2B5949F8D26@msqr.us> <20131106035350.GC59496@kib.kiev.ua> <527A6012.2050500@vangyzen.net> <60595DA5-A339-4FA5-99FD-FC25591A6BDA@msqr.us> <20131107230834.GS59496@kib.kiev.ua> <20131108080938.GT59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20131108080938.GT59496@kib.kiev.ua> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Alex Pavlovic , Matt Magoffin , freebsd-stable@freebsd.org, Eric van Gyzen X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2013 05:42:28 -0000 On (08/11/2013 10:09), Konstantin Belousov wrote: > On Fri, Nov 08, 2013 at 05:16:13PM +1300, Matt Magoffin wrote: > > On Nov 8, 2013, at 12:08 PM, Konstantin Belousov wrote: > > > > >> From a 9.2 amd64 virtual machine, this is what I get: > > >> > > >> (kgdb) list *VOP_ADD_WRITECOUNT_APV+0x78 > > >> 0xffffffff80d96898 is in VOP_ADD_WRITECOUNT_APV (vnode_if.c:4236). > > >> 4231 in vnode_if.c > > >> > > >> Does this help? > > >> > > > I need the code around this line; corresponding file is generated, I > > > do not have it. > > > > I generated vnode_if.c using this command: > > > > /usr/bin/awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -c > > > > I just inferred that command, I do not know if that is correct. Here are lines 4219-4264 from the file: > > > > int > > VOP_ADD_WRITECOUNT_APV(struct vop_vector *vop, struct vop_add_writecount_args *a) > > { > > int rc; > > > > VNASSERT(a->a_gen.a_desc == &vop_add_writecount_desc, a->a_vp, > > ("Wrong a_desc in vop_add_writecount(%p, %p)", a->a_vp, a)); > > while(vop != NULL && \ > > vop->vop_add_writecount == NULL && vop->vop_bypass == NULL) > > vop = vop->vop_default; > > VNASSERT(vop != NULL, a->a_vp, ("No vop_add_writecount(%p, %p)", a->a_vp, a)); > > SDT_PROBE(vfs, vop, vop_add_writecount, entry, a->a_vp, a, 0, 0, 0); > > > > ASSERT_VI_UNLOCKED(a->a_vp, "VOP_ADD_WRITECOUNT"); > > ASSERT_VOP_ELOCKED(a->a_vp, "VOP_ADD_WRITECOUNT"); > > VFS_PROLOGUE(a->a_vp->v_mount); > So which line is 4236 ? That one ^^^^ ? > > If yes, I absolutely need you to obtain core dump and than print *a > and *(a->a_vp) from the debugger, to make further progress. > > > if (vop->vop_add_writecount != NULL) > > rc = vop->vop_add_writecount(a); > But, if I mis-counted and the line 4236 is that one ^^^^, than together > with the panic message > panic: vm_fault: fault on nofault entry, addr: ffffff836e0fc000 > which suggests that vop_add_writecount not NULL but garbage, I believe > that your issue is stale module, compiled on 9.1 but used on 9.2. Shouldn't we guarantee KABI stability far stable releases? There is similar problem reported for pefs panicing on 9.2 if installed from binary packages: https://github.com/glk/pefs/issues/12 VOP vector is garbage in this case. (kgdb) fr 8 #8 0xc0f6ef6a in VOP_ADD_WRITECOUNT_APV (vop=0xc7abd580, a=0xe7fd9ae8) at vnode_if.c:4236 4236 vnode_if.c: No such file or directory. in vnode_if.c (kgdb) p *vop $1 = {vop_default = 0xc1261120, vop_bypass = 0, .... vop_setlabel = 0, vop_vptofh = 0xc7ab1350 , vop_vptocnp = 0xc0b6b130 , vop_allocate = 0, vop_advise = 0, vop_unp_bind = 0, vop_unp_connect = 0, vop_unp_detach = 0, vop_is_text = 0, vop_set_text = 0, vop_unset_text = 0, vop_get_writecount = 0, vop_add_writecount = 0xc7ab7360 , vop_spare4 = 0xc7ab7340 , vop_spare5 = 0xc7ab7310 } pefs is not the only kernel module packages are built for. How should we handle KABI breakage in 9.x for packages then? Thanks, Gleb.