Re: [PATCH] DAC960_Release bug (2.4.x)

[John v/d Kamp]

We have an application that detects hardware using the libhd from SuSE.
This lib loads the driver with the NONBLOCK flag, because it doesn't want
to use the drive, but only detect it. When it releases, the File parameter
is NULL, so the counters get decremented, but were never incremented.

When we try to partition the drive, the BLKRRPART ioctl fails because the
counter is 4294967295. (-1)
I don't think any program relies on this counter being < "0".

The whole point on the file descriptor is beyond me, but I think it's a
good thing to address.

--
John van der Kamp, ConnecTUX

On Wed, 16 Apr 2003, Dave Olien wrote:

>
> As you observed, ControllerUsageCount doesn't seem to serve
> any purpose.  It should just be removed, I think.
>
> I'm curious, what application you have that calls DAC960_Open() with NONBLOCK.
>
> Here's my interpretation of what the drivers' trying to do here.
> If you can validate these assumptions, I'd appreciate it.
>
> For the DAC960, it looks like the NONBLOCK flag is just a trick
> to allow a user-level DAC960 RAID manager utility to open the driver
> without actually interacting with any disk devices on the controller.
> The file descriptor you get back is not really associated with a specific
> device or controller.
>
> The DAC960_IOCTL function calls DAC960_UserIOCTL only when the
> NONBLOCK flag is set.  DAC960_UserIOCTL is designed to operate on
> the controller specified by a controller number argument, rather than
> a controller associated with its file descriptor argument.
>
> This lets the RAID manager utility operate on any controller at a time
> when perhaps there are NO logical devices ONLINE (i.e. you would
> be normally UNABLE to get ANY file descriptor for that controller).
>
> The ModuleOnly label in DAC960_open() apparently is meant to indicate
> we're opening "the DAC960 module" rather than a specific device.
>
> The problem is, the test for opening this file descriptor is iffy:
> 	"If the file descriptor is for controller 0, logical device
> 	0, and NONBLOCK is set, then return this `special` file descriptor."
>
> It's perfectly reasonable for an application to actually want to open
> REAL devices this way.  Instead, it gets this peculiar file descriptor.
>
> The problem is there are DAC960 utilities out there that I'm sure rely
> on this behavior.  So, it'll be hard to fix "the right way".
>
>