kern/49171: panic when closing a pty

[apb%cequrux.com@localhost]

>Number:         49171
>Category:       kern
>Synopsis:       panic when closing a pty
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Sep 01 20:00:00 +0000 2014
>Originator:     Alan Barrett
>Release:        NetBSD 7.99.1
>Organization:
Not much
>Environment:
NetBSD 7.99.1 i386
>Description:
Sometimes, when I exit from a shell inside a virtual window inside
screen, I get a panic, apparently from ptyfs_reclaim passing a NULL
struct mount * pointer as the first arg to vcache_remove.

This is a new problem since the changes to ptyfs a few weeks ago.

>How-To-Repeat:
Install screen from pkgsrc/misc/screen.

Run screen inside an xterm.

Open several shell windows inside screen.

Use some of the shell windows actively, and let some stay idle for a
while.

Switch to an idle window and press ^D (end of file).  This sill
sometimes exit the shell and close the screen window, as desired, but it
will sometimes crash.

Here's a backtrace:

breakpoint(c0d93734,c104f880,c0cc9c94,dd8dcd9c,0,0,8,dd8dcd90,c0a6a9b4,c0cc9c94)
 at breakpoint+0x4
vpanic(c0cc9c94,dd8dcd9c,dd8dcdd0,c09e6dae,c0cc9c94,c0cc9e45,c0ccb859,c0d9680c,5
91,c597dc38) at vpanic+0x121
kvtopte.part.1(c0cc9c94,c0cc9e45,c0ccb859,c0d9680c,591,c597dc38,cfc039ec,d2bcbe3
0,0,d2bcbe30) at kvtopte.part.1
vcache_remove(0,d2bcbe30,8,c9b9a580,dd8dce08,c0a008e7,dd8dcdfc,0,c0cb8e14,c0cb8d
f0) at vcache_remove+0x13f
ptyfs_reclaim(dd8dcdfc,0,c0cb8e14,c0cb8df0,c9b9a580,1,dd8dce40,c09e3eed,c9b9a580
,dd8dce33) at ptyfs_reclaim+0x2d
VOP_RECLAIM(c9b9a580,dd8dce33,ffffffff,c53e9560,0,0,4,18dce50,c53e9560,c9b9a580)
 at VOP_RECLAIM+0x4a
vclean(ce0e11c0,cddb62d0,dd8dce80,c09e612e,c9b9a580,509,0,dd8dce70,c104bc0c,4) a
t vclean+0xdd
vgone(c9b9a580,509,0,dd8dce70,c104bc0c,4,c9b9a580,cddb62d0,c53e9560,c8219040) at
 vgone+0x3c
vrevoke(cddb62d0,dd8dceb0,c0a001e7,dd8dcea0,8,c0637190,c0cb9000,cddb62d0,1,c8219
040) at vrevoke+0x92
genfs_revoke(dd8dcea0,8,c0637190,c0cb9000,cddb62d0,1,c8219040,dd8dcf24,c06371a3,
cddb62d0) at genfs_revoke+0x1a
VOP_REVOKE(cddb62d0,1,1,c7479a40,0,c0643d08,c7a7c588,c7a7c588,cddb62d0,c8219054)
 at VOP_REVOKE+0x4a
exit1(c53e9560,0,c53e9560,dd8dcfa8,dd8dcf9c,c08dbcd3,c53e9560,dd8dcf68,dd8dcf60,
81c7000) at exit1+0x677
sys_exit(c53e9560,dd8dcf68,dd8dcf60,81c7000,c8437370,c0f5a92c,dd8dcf68,0,0,0) at
 sys_exit+0x36
syscall() at syscall+0x83
--- syscall (number 1) ---

Notice the NULL first argument to vcache_remove.  This NULL is passed
to hash32_buf which tries to access memory through the pointer, and
triggers a panic

Let's examine the pointer passed to ptyfs_reclaim:

crash> exa/xl dd8dcdfc
dd8dcdfc:       c0cb8df0

c0cb8df0 should be a pointer to a vnode.

crash> show vnode c0cb8df0
crash> show vnode/f c0cb8df0

No output.  I wonder why.  At least its not a pointer to a
completely zeroed struct vnode:

crash> exa/m c0cb8df0,10
vop_reclaim_desc:       20000000 a69fd9c0 00000000 0c8ecbc0      ...............

vop_reclaim_desc+0x10:  ffffffff ffffffff ffffffff 04000000     ................

vop_reclaim_vp_offsets+0x4:     ffffffff 1f000000 b29fd9c0 00010000     ........
........
vop_inactive_desc+0xc:  308ecbc0 ffffffff ffffffff ffffffff     0...............


In case it makes any difference, I use init.chroot to run almost
everything except the kernel in a chroot; the /dev in the chroot is
a symlink to /dev.@machine, which resolves to /dev.i386 due to magic
symlinks.  mount(8) inside the chroot shows:

    ptyfs on /dev.i386/pts type ptyfs (local)

>Fix: