From owner-freebsd-stable@FreeBSD.ORG Thu Dec 20 13:22:33 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABD5116A469 for ; Thu, 20 Dec 2007 13:22:33 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 6B77C13C447 for ; Thu, 20 Dec 2007 13:22:32 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id A3CFF74400F; Thu, 20 Dec 2007 14:59:13 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjDNZhbOHwlh; Thu, 20 Dec 2007 14:59:13 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 81EC474400E; Thu, 20 Dec 2007 14:59:13 +0200 (EET) Message-ID: <476A6721.5020404@icyb.net.ua> Date: Thu, 20 Dec 2007 14:59:13 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 References: <475FC26C.3030508@icyb.net.ua> <200712130930.08558.nvass@teledomenet.gr> <4760FE68.60001@icyb.net.ua> <200712131213.37478.nvass@teledomenet.gr> <47610957.8020800@icyb.net.ua> In-Reply-To: <47610957.8020800@icyb.net.ua> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Nikos Vassiliadis Subject: mounted cd, tray locking, cdcontrol X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2007 13:22:33 -0000 FreeBSD 6.2-RELEASE-p6 amd64 This is what "cdcontrol eject" performs (incidentally, on a mounted acd device): 11991 cdcontrol CALL open(0x7fffffffe130,0,0x9) 11991 cdcontrol NAMI "/dev/acd0" 11991 cdcontrol RET open 3 11991 cdcontrol CALL ioctl(0x3,CDIOCALLOW,0) 11991 cdcontrol RET ioctl 0 11991 cdcontrol CALL ioctl(0x3,CDIOCEJECT,0) 11991 cdcontrol RET ioctl -1 errno 16 Device busy 11991 cdcontrol CALL exit(0xffffffff) This is how handling of the above ioctls looks in atapi-cd.c: ... case CDIOCALLOW: error = acd_prevent_allow(dev, 0); cdp->flags &= ~F_LOCKED; break; ... case CDIOCEJECT: if (pp->acr != 1) { error = EBUSY; break; } error = acd_tray(dev, 0); break; ... In other words: CDIOCALLOW - unconditionally send "allow" to the device CDIOCEJECT - if device is opened by anybody else other than ioctl issuer then return EBUSY, otherwise send "stop (without eject)", "allow", "eject". So, if you issue cdcontrol eject on a mounted (or otherwise opened device) the net result is weird: CD tray is not ejected but it is unlocked, i.e pressing a button on the physical device will eject the tray. I think this is messy. The most obvious target is cdcontrol - it doesn't have to issue CDIOCALLOW and actually this ioctl creates all the mess (but read about SCSI devices below). Possible secondary target: maybe CDIOCALLOW should also do some checking of current access to the device. BTW, it would be also nice to have separate 'allow' and 'prevent' commands of cdcontrol, if just for the sake of testing. >From a cursory glance at scsi_cd.c it seems that for SCSI CD-ROMs there are no "in-use" checks for either of the ioctls: CDIOCALLOW - unconditionally send "allow" to the device CDIOCEJECT - unconditionally send "eject" I am not sure if I like this but at least this is consistent: if I'd issue "cdcontrol eject" on a cd device, then it would be actually ejected no matter what. (And this is exactly because of the explicit CDIOCALLOW from cdcontrol, because "prevent" was internally issued to a drive on device open). For acd it neither ejects nor preserves original state. So another target is inconsistency in ioctl handling between cd and acd. And I don't want yet to cloud the matters with interaction between scsi-cd driver and atapi-cd driver when atapicam is enabled :-) P.S. a PR with a terse description is already opened for the above behavior of acd: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/118779 -- Andriy Gapon