From owner-freebsd-bugs Wed Jun 5 15:50:17 2002 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 74DC437B403 for ; Wed, 5 Jun 2002 15:50:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g55Mo3R79159; Wed, 5 Jun 2002 15:50:03 -0700 (PDT) (envelope-from gnats) Date: Wed, 5 Jun 2002 15:50:03 -0700 (PDT) Message-Id: <200206052250.g55Mo3R79159@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bruce Evans Subject: Re: kern/38923: Incorrect device use count prevents door locking Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR kern/38923; it has been noted by GNATS. From: Bruce Evans To: "Igor A. Goussarov" Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/38923: Incorrect device use count prevents door locking Date: Thu, 6 Jun 2002 08:48:10 +1000 (EST) > >Synopsis: Incorrect device use count prevents door locking > >Description: > I have an Iomega ZIP drive, which I wish to mount and use. The problem is that the drive is not locked when it is mounted. Back in FreeBSD 3.3, when I was using wfd device, the disk cannot be ejected while it was in use. > Now, in 4.4, the disk is not locked in the drive. Please use lines of length somewhat shorter than 220 characters. > I've tracked the problem down to /usr/src/sys/dev/ata/atapi-fd.c file. The function afdopen is supposed to lock the drive if the count_dev for the device being opened indicates that this is the first use of the device. > And it _does_ lock the drive if I were to open it as /dev/afd0. But it _does_not_ lock the device if I try to open it as /dev/afd0s4 (which is a-must for msdos-formatted zip media). > The problem is that count_dev return 0 instead of 1 in the latter case. My kernel debugging capabilities are limited so I can't examine the problem any further... This is due to count_dev() not actually working. I have had the following fix in my kernel for a year or two since first reporting ejection bugs in the ata drivers, but my afd drive has mostly been offline so I have barely tested them. %%% Index: atapi-fd.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ata/atapi-fd.c,v retrieving revision 1.72 diff -u -2 -r1.72 atapi-fd.c --- atapi-fd.c 25 May 2002 11:18:02 -0000 1.72 +++ atapi-fd.c 25 May 2002 12:59:56 -0000 @@ -235,6 +236,5 @@ atapi_test_ready(fdp->device); - if (count_dev(dev) == 1) - afd_prevent_allow(fdp, 1); + afd_prevent_allow(fdp, 1); if (afd_sense(fdp)) @@ -258,6 +258,5 @@ struct afd_softc *fdp = dev->si_drv1; - if (count_dev(dev) == 1) - afd_prevent_allow(fdp, 0); + afd_prevent_allow(fdp, 0); return 0; } %%% How this fix is supposed to work: Upper layers of the disk driver are supposed to call the driver's open and close functions only for first open and last close of a logical subdevice. Thus there is no need for the driver's functions to check the counts -- the non-broken counts are known to be 1 in both. This seems to be working correctly for opens of different subdevices, but not for opens of the same subdevice, since the driver shoots itself in the foot using the D_TRACKCLOSE flag. D_TRACKCLOSE causes the device close function to be called on every close so that the function can keep track of the closes, but this just confuses the upper layers of the disk driver and causes extra work and brokenness here -- in -current, the count_dev() limits ejection enable to the very last close and my fix breaks this. The confusion in the upper layer may be fatal in some cases. Please try removing D_TRACKCLOSE if you try my patch. I reported problems with D_TRACKCLOSE a year or two ago but haven't tried fixing it. There doesn't seem to be a single example of non-foot-shooting use of D_TRACKCLOSE in the tree. The acd and ast drivers have variarations of these bugs. The problems are are mostly worked around in the acd driver by unsupporting subdevices. They are harder to fix properly than in the afd driver since there is no upper layer to keep track of the subdevices. These bugs have a long history. They were in the first version of the wfd driver in 1998. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message