Re: kern/50467: Panic from disconnecting phone while reading its contents

["J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>]

The following reply was made to PR kern/50467; it has been noted by GNATS.

From: "J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/50467: Panic from disconnecting phone while reading its contents
Date: Sun, 20 Mar 2016 14:32:08 +0100

 The two interesting threads are:
 
 0.58 (usb1) is detaching the umass device, its trace is
 
 scsipi_execute_xs() at scsipi_execute_xs+0x1d2
 sd_flush() at sd_flush+0x88
 sdlastclose() at sdlastclose+0x75
 sdclose() at sdclose+0x75
 bdev_close() at bdev_close+0x86
 spec_close() at spec_close+0x274
 VOP_CLOSE() at VOP_CLOSE+0x33
 spec_node_revoke() at spec_node_revoke+0x9a
 vclean() at vclean+0x2e8
 vgone() at vgone+0x56
 vrevoke() at vrevoke+0x8f
 genfs_revoke() at genfs_revoke+0x13
 VOP_REVOKE() at VOP_REVOKE+0x32
 vdevgone() at vdevgone+0x4f
 sddetach() at sddetach+0xb4
 config_detach() at config_detach+0xf8
 scsipi_target_detach() at scsipi_target_detach+0xbc
 scsibusdetach() at scsibusdetach+0x36
 config_detach() at config_detach+0xf8
 umass_detach() at umass_detach+0xa0
 config_detach() at config_detach+0xf8
 usb_disconnect_port() at usb_disconnect_port+0xae
 uhub_explore() at uhub_explore+0x180
 uhub_explore() at uhub_explore+0x9b
 usb_discover.isra.2() at usb_discover.isra.2+0x4e
 usb_event_thread() at usb_event_thread+0x74
 
 483.1 (cp) writing to the file system on umass device
 
 kern_assert() at kern_assert+0x4f
 spec_strategy() at spec_strategy+0x91
 VOP_STRATEGY() at VOP_STRATEGY+0x33
 bio_doread() at bio_doread+0x90
 bread() at bread+0x1a
 pcbmap() at pcbmap+0x181
 msdosfs_bmap() at msdosfs_bmap+0xe7
 VOP_BMAP() at VOP_BMAP+0x61
 genfs_getpages() at genfs_getpages+0x104c
 VOP_GETPAGES() at VOP_GETPAGES+0x71
 ra_startio() at ra_startio+0x72
 uvm_ra_request() at uvm_ra_request+0x1a3
 uvn_get() at uvn_get+0xeb
 uvm_fault_internal() at uvm_fault_internal+0x11de
 trap() at trap+0x32a
 --- trap (number 6) ---
 copyin() at copyin+0x34
 uiomove() at uiomove+0xe4
 ubc_uiomove() at ubc_uiomove+0xf7
 ffs_write() at ffs_write+0x2d6
 VOP_WRITE() at VOP_WRITE+0x37
 vn_write() at vn_write+0xec
 dofilewrite() at dofilewrite+0x97
 sys_write() at sys_write+0x5f
 syscall() at syscall+0x9c
 --- syscall (number 4) =E2=80=94
 
 At this point sd_bdevvp is NULL while the vnode is becoming dead.
 
 Its op vector is still valid, not deadfs so it is ok for spec_strategy
 to be called here.
 
 We could change the assertion to
 
 	KASSERT(vp->v_specnode->sn_dev->sd_bdevvp =3D=3D NULL ||
 	    vp =3D=3D vp->v_specnode->sn_dev->sd_bdevvp)
 
 or check for dead (or becoming dead) vnodes first
 
 	mutex_enter(vp->v_interlock);
 	error =3D vdead_check(vp, VDEAD_NOWAIT);
 	mutex_exit(vp->v_interlock);
 
 	if (error) {
 		bp->b_error =3D EIO;
 
 --
 J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)