9.2-RELEASE amd64 panic: vn_open_cred

[Gleb Kurtsou]

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 <kostikbel at gmail.com> 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 <pefs_vptofh>, 
  vop_vptocnp = 0xc0b6b130 <vop_stdvptocnp>, 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 <pefs_aes_encrypt>, 
  vop_spare4 = 0xc7ab7340 <pefs_aes_decrypt>, 
  vop_spare5 = 0xc7ab7310 <pefs_aes_keysetup>}


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.