USB stack getting confused

[Hans Petter Selasky]

On 3/9/19 7:41 PM, Warner Losh wrote:
>> Newer apcupsd seems to open /dev/ugen only for the duration of the query,
>> which makes the erratic behaviour is much less likely, but could still
>> cause
>> breakage when device disappear while apcupsd has it opened.
>>
> Is there a form of destroy_dev() that does a revoke on all open instances?
> Eg, this is gone, you can't use it anymore, and all further attempts to use
> the device will generate an error, but in the mean time we destroy the
> device and let the detach routine get on with life. waiting may make sense
> when you are merely unloading the driver (and getting to the detach routine
> that way), but when the device is gone, I've come around to the point of
> view that we should just destroy it w/o waiting for closes and anybody that
> touches it afterwards gets an error and has to cope with the error. But
> even in the unload case, we maybe we shouldn't get to the detach routine
> unless we're forcing and/or the detach routine just returns EBUSY since the
> only one that knows what dev_t's are associated with the device_t is the
> driver itself.

Hi,

There are multiple issues here:

1) The USB stack use device numbers from device_get_unit() when creating 
character devices. That means it must wait at least until the VNODE in 
/dev is removed, and the same device name can be re-used.

2) When disconnecting the "struct file" from the USB, lost memory might 
pile up if these daemons which are typically created by devd don't get 
killed.

Many of these applications are using libusb. We can add a heartbeat 
thread inside there to simply close the ugen device handle when we 
understand the device is gone. That will close 99% of these issues.

--HPS


--HPS