kern/169495: panic after cam scsi cd device loss (patch included)

Steven Hartland steven.hartland at multiplay.co.uk
Wed Jun 27 18:40:10 UTC 2012


>Number:         169495
>Category:       kern
>Synopsis:       panic after cam scsi cd device loss (patch included)
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jun 27 18:40:10 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator:     Steven Hartland
>Release:        8.3-RELEASE
>Organization:
Multiplay
>Environment:
FreeBSD blade26.multiplay.co.uk 8.3-RELEASE-p3 FreeBSD 8.3-RELEASE-p3 #114: Wed Jun 27 17:26:53 UTC 2012     root at build:/usr/obj/usr/src/sys/MULTIPLAY  amd64
>Description:
While testing a kernel patch we ended with a reproducable panic when disconnecting the IPMI cd device.

The panic is from the force panic in cam_periph_release_locked_buses on 8.3
panic("%s: release of %p when refcount is zero\n ", __func__, periph);

After much investigation it turns out cam/scsi_cd.c isn't testing the return from cam_periph_hold in cdclose.
>How-To-Repeat:
This is hard to repeat on a stock kernel as it seems to be very timing dependent but on our machine disconnecting the IPMI cd device causes the panic.
>Fix:
The fix is to test the return code from cam_periph_hold as done by the scsi da device, see patch attached.

Patch attached with submission follows:

--- /usr/src/sys/cam/scsi/scsi_cd.c.orig	2012-06-27 17:20:12.902599170 +0000
+++ /usr/src/sys/cam/scsi/scsi_cd.c	2012-06-27 17:39:11.567322238 +0000
@@ -1041,7 +1041,11 @@
 	softc = (struct cd_softc *)periph->softc;
 
 	cam_periph_lock(periph);
-	cam_periph_hold(periph, PRIBIO);
+	if (cam_periph_hold(periph, PRIBIO) != 0) {
+		cam_periph_unlock(periph);
+		cam_periph_release(periph);
+		return (0);
+	}
 
 	if ((softc->flags & CD_FLAG_DISC_REMOVABLE) != 0)
 		cdprevent(periph, PR_ALLOW);


>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list