From owner-freebsd-scsi@freebsd.org Tue Jun 13 21:32:50 2017 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 170CBBFEF5B for ; Tue, 13 Jun 2017 21:32:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F1D3E6A02E for ; Tue, 13 Jun 2017 21:32:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v5DLWnge028330 for ; Tue, 13 Jun 2017 21:32:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-scsi@FreeBSD.org Subject: [Bug 219857] panic in scsi_cd code Date: Tue, 13 Jun 2017 21:32:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ken@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-scsi@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 21:32:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219857 Kenneth D. Merry changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open CC| |ken@FreeBSD.org --- Comment #1 from Kenneth D. Merry --- I can see why this happened. It is a little strange that I don't recall se= eing this before, since the media check code was added in 2003, and it appears t= hat sleeping has been prohibited for a similar amount of time. The problem is: 1. In g_io_schedule_down(), THREAD_NO_SLEEPING() is called before the start routine is called. 2. In cdstrategy(), if the CD_FLAG_VALID_MEDIA flag isn't set, the cd(4) driver probes to see if there is valid media in the drive. 3. In cdcheckmedia(), the cd(4) driver first prevents CD removal by calling cdprevent(). 4. In cdprevent(), the cd(4) driver calls cdrunccb(), which calls cam_periph_runccb(), which sleeps and runs into the panic. In most cases, this won't happen because the cd(4) driver checks for media = on open(), and prevents removal when it finds media. The driver does allow the open() when no media is present, so that the user can call the CDIOCCLOSE a= nd CDIOCEJECT ioctls. One possible solution is just failing the I/O in cdstrategy() if the CD_FLAG_VALID_MEDIA flag is not set. We would need to add code that checks= for media if the user does a CDIOCCLOSE ioctl. The challenge there, however, is that it would not catch the case where the user physically closes the drive while they have the device open and then s= ends a read. In order to handle that case, and not sleep underneath cdstrategy(), we wou= ld need to do an asynchronous media check. The way I would probably do it is to add a series of states into cdstart() = and cddone() that mirror the way that cdcheckmedia() operates. So, prevent, re= ad capacity, read TOC, and so on. We would still call xpt_schedule() from cdstrategy(), but cdstart() would go into a media probe state machine to de= tect the media and once it has validated the media or not, satisfy the I/O or se= nd it back with an error. As a bonus, we would re-implement the existing code so that it can work eit= her asynchronously or synchronously. (To avoid duplicate code paths.) --=20 You are receiving this mail because: You are the assignee for the bug.=