port-i386/53852: assert fails in function vclean() from telnetd context

[seearun%gmail.com@localhost]

>Number:         53852
>Category:       port-i386
>Synopsis:       assert fails in function vclean() from telnetd context
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-i386-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jan 10 11:40:00 +0000 2019
>Originator:     Arun D
>Release:        7.1.2
>Organization:
>Environment:
I am having the vfs_vnode.c v 1.37.2.2 where is see the issue.
The crash is seen in i386 arch.
>Description:
The following is the kernel backtrace during the crash

#0  ?? () at ../../../../arch/i386/i386/cpufunc.S:217
217     ../../../../arch/i386/i386/cpufunc.S: No such file or directory.
#0  ?? () at ../../../../arch/i386/i386/cpufunc.S:217
#1  0xc040ad14 in vpanic (fmt=fmt@entry=0xc0586214 "kernel %sassertion \"%s\" failed: file \"%s\", line %d ", ap=ap@entry=0xe22bdb68 "\301^X\300\260\r^\300\002\n^\300\324\003") at ../../../../kern/subr_prf.c:443
#2  0xc054ed13 in kern_assert (fmt=<optimized out>, fmt@entry=0xc0586214 "kernel %sassertion \"%s\" failed: file \"%s\", line %d ") at ../../../../../../lib/libkern/kern_assert.c:51
#3  0xc04ebeb4 in vclean (vp=vp@entry=0xc8aef9ac) at ../../../../kern/vfs_vnode.c:979
#4  0xc04ee4cf in vgone (vp=0xc8aef9ac) at ../../../../kern/vfs_vnode.c:1153
#5  0xc04ee5cb in vrevoke (vp=0xc8aef9ac) at ../../../../kern/vfs_vnode.c:1132
#6  0xc01e761a in genfs_revoke (v=0xe22bdc04) at ../../../../miscfs/genfs/genfs_vnops.c:276
#7  0xc04fbc1c in VOP_REVOKE (vp=0xc8aef9ac, flags=flags@entry=0x1) at ../../../../kern/vnode_if.c:656
#8  0xc0468c99 in pty_grant_slave (l=l@entry=0xc8aeed40, dev=0x501, mp=0x0) at ../../../../kern/tty_ptm.c:258
#9  0xc046900d in ptmioctl (dev=0xa501, cmd=0x48087446, data=0xc78c1008, flag=0x3, l=0xc8aeed40) at ../../../../kern/tty_ptm.c:410
#10 0xc03f8a20 in cdev_ioctl (dev=0xa501, cmd=0x48087446, data=0xc78c1008, flag=0x3, l=0xc8aeed40) at ../../../../kern/subr_devsw.c:918
#11 0xc03ec986 in spec_ioctl (v=0xe22bdda0) at ../../../../miscfs/specfs/spec_vnops.c:918
#12 0xc04fba4e in VOP_IOCTL (vp=vp@entry=0xc7c420bc, command=command@entry=0x48087446, data=data@entry=0xc78c1008, fflag=0x3, cred=0xc618af00) at ../../../../kern/vnode_if.c:530
#13 0xc04f05c1 in vn_ioctl (fp=0xc8a2b540, com=0x48087446, data=0xc78c1008) at ../../../../kern/vfs_vnops.c:763
#14 0xc04180fa in sys_ioctl (l=0xc8aeed40, uap=0xe22bdf68, retval=0xe22bdf60) at ../../../../kern/sys_generic.c:690
#15 0xc0425262 in sy_call (rval=0xe22bdf60, uap=0xe22bdf68, l=0xc8aeed40, sy=<optimized out>) at ../../../../sys/syscallvar.h:61
#16 sy_invoke (code=0x36, rval=0xe22bdf60, uap=0xe22bdf68, l=0xc8aeed40, sy=<optimized out>) at ../../../../sys/syscallvar.h:85
#17 syscall (frame=0xe22bdfa8) at ../../../../arch/x86/x86/syscall.c:156
#18 0xc01005a6 in ?? () at ../../../../arch/i386/i386/locore.S:1174
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) fr 3
#3  0xc04ebeb4 in vclean (vp=vp@entry=0xc8aef9ac) at ../../../../kern/vfs_vnode.c:979
979     ../../../../kern/vfs_vnode.c: No such file or directory.
(gdb) p vp
$1 = (vnode_t *) 0xc8aef9ac
(gdb) p vp->v_vflag
$2 = 0x34
gdb) x /10a vp->v_op
0xc617c8c8:     0xc014e4b0 <dead_default_error> 0xc01e7440 <genfs_nullop>       0xc014e4d0 <dead_lookup>        0xc014e4b0 <dead_default_error>
0xc617c8d8:     0xc014e4b0 <dead_default_error> 0xc014e4f0 <dead_open>  0xc01e7440 <genfs_nullop>       0xc014e4b0 <dead_default_error>
0xc617c8e8:     0xc014e4b0 <dead_default_error> 0xc014e4b0 <dead_default_error>
(gdb) p dead_vnodeop_p
$1 = (int (**)(void *)) 0xc617c8c8
(gdb) p vp->v_op
$2 = (int (**)(void *)) 0xc617c8c8


>From the core file vp->v_op is initialized with dead_vnodeop_p. I guess it is not expected. 
Hence the below condition in the function vclean() fails
"   KASSERT((vp->v_vflag & VV_LOCKSWORK) == 0 ||
        VOP_ISLOCKED(vp) == LK_EXCLUSIVE);
"
This issue is not seen always.
>How-To-Repeat:
The problem is seen when doing telnet very rarely 
>Fix: