kern/109152: [rp] RocketPort panic from device_unbusy()

[Craig Leres]

>Number:         109152
>Category:       kern
>Synopsis:       [rp] RocketPort panic from device_unbusy()
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Feb 14 05:50:04 GMT 2007
>Closed-Date:
>Last-Modified:
>Originator:     Craig Leres
>Release:        FreeBSD 6.2-RELEASE i386
>Organization:
Lawrence Berkeley National Laboratory
>Environment:
	% uname -a
	FreeBSD ee.lbl.gov 6.2-RELEASE FreeBSD 6.2-RELEASE #1: Mon Jan 15 11:31:32 PST 2007     leres at fox.ee.lbl.gov:/usr/src/6.2-RELEASE/sys/i386/compile/LBLSMP  i386

	rp0: <RocketPort PCI> port 0x3000-0x30ff irq 19 at device 7.0 on pci2
	RocketPort0 (Version 3.02) 32 ports.

>Description:
	Removing a devfs symlink can cause a panic if a program had
	that symlink open and then exits.

	I use the comms/conserver port to manage a bunch of serial
	lines connected to a 32 port RocketPort config. To keep
	track of what each line is connected to, I create symlinks
	via "link" lines in devfs.conf. I disovered that if I remove
	link lines from devfs.conf, update devfs and then kill off
	a conserver that has one or more of the obsolete links open,
	the system will panic.

>How-To-Repeat:
	Append a line to devfs.conf:

	    link cuaR00 test

	Update devfs and verify the new symlink:

	    # /etc/rc.d/devfs restart
	    # ls -l /dev/test /dev/cuaR00
	    crw-rw----  1 uucp  dialer    0,  40 Feb 12 19:45 /dev/cuaR00
	    lrwxr-xr-x  1 root  wheel          6 Feb 12 19:45 /dev/test -> cuaR00

	Add a line to conserver.cf:

	    test:/dev/test:9600p:/var/console/test.log:0

	Startup conserver.
	Remove out the link line previously added to devfs.conf.
	Update devfs again.
	Note that the /dev/test symlink still exists.
	Kill conserver.
	The system panics with:

	    device_unbusy: called for non-busy device rp0

	kgdb shows:

	    (kgdb) bt
	    #0  0xc0692c96 in doadump ()
	    #1  0xc06931f2 in boot ()
	    #2  0xc0693519 in panic ()
	    #3  0xc06a9304 in device_unbusy ()
	    #4  0xc05ca8e9 in rpclose ()
	    #5  0xc06c6617 in ttyclose ()
	    #6  0xc066878b in giant_close ()
	    #7  0xc0644876 in devfs_close ()
	    #8  0xc08ae164 in VOP_CLOSE_APV ()
	    #9  0xc06fa8c6 in vn_close ()
	    #10 0xc06fb836 in vn_closefile ()
	    #11 0xc06448b7 in devfs_close_f ()
	    #12 0xc0672a04 in fdrop_locked ()
	    #13 0xc0672951 in fdrop ()
	    #14 0xc0670eef in closef ()
	    #15 0xc066e04d in close ()
	    #16 0xc08998f3 in syscall ()
	    #17 0xc08853df in Xint0x80_syscall ()
	    #18 0x00000033 in ?? ()
	    Previous frame inner to this frame (corrupt stack?)
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: