Date: Wed, 5 Jun 2002 15:50:03 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/38923: Incorrect device use count prevents door locking Message-ID: <200206052250.g55Mo3R79159@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/38923; it has been noted by GNATS.
From: Bruce Evans <bde@zeta.org.au>
To: "Igor A. Goussarov" <igusarov@akella.com>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206052250.g55Mo3R79159>