Re: [linux-usb-devel] Re: bug 2400

[David Brownell <david-b@pacbell.net>]

James Bottomley wrote:
> On Sun, 2004-04-04 at 22:54, David Brownell wrote:
> 
>>Which directly follows from what I said ... USB propagates
>>that knowledge in carefully defined ways.   Other layers can
>>do the same, although clearly state associated with open file
>>descriptors needs to use a slightly different strategy.  And
>>that strategy is what Alan's original comment was about.
> 
> 
> Well, again, this is at the core of the argument.
> 
> I say that as long as we have all our objects correctly refcounted, how
> disconnections propagate up the stack is irrelevant.

"Irrelevant" is pointlessly strong, even for what I'm guessing
you really mean to be saying.

Minimally, there needs to be synchronization to prevent open() on
one CPU from using data structures disconnect() just invalidated
on another CPU.  That's a basic "how to write multi-threaded code"
kind of issue, which I won't bother to explain (yet again).


> If you have to have a "carefully defined" order for the propagation of
> an asynchronous event to save you from oopsing, it's a sure sign of bugs
> in the code.

It was "carefully defined" to ensure that there are clearly
defined points where it's safe to delete the hardware state.
Those are needed in situations other than disconnect().

Not having such synchronization points meant that HCDs were
reduced to _guessing_ whether it's safe to free that state.
Which was a sure sign of API bugs (inside usbcore), and made
for way too many oops-on-unplug reports in 2.4 kernels (and
kept various other things from working right, too).


> My reasoning is that I/O down the stack will ultimately hit the part of
> the kernel (or even just timeout in transmission to the device if it's
> disappeared without trace) that contains the knowledge and be returned
> with an error.  Ordering the disconnection propagation cannot change
> this fact, merely alter *which* component returns the error.

Ensuring such a behaviour certainly requires "careful design".
As does ensuring that the event propagation _completes_ every
time, rather than sometimes just refusing to finish.  Surely
you've seen both kinds of design botch.


> As long as we're robust to the error there is no problem.

The only system "error" in this discussion was that oops.

It may be a minor point ... but "disconnecting device while in use"
isn't an error at all.  It's a fault, maybe sometimes undesirable,
but one with behavior specified as fully as reading or writing a
block of data.


> At this point, the object lifetime does nothing more that count how long
> we have to keep the object around to return the error.

And that's basically what I said about the careful design of the
disconnect sequence, ensuring that there _is_ such a point:  one
where the only issues left are when references get dropped, so
that the only issue left is memory management.

- Dave



> James
> 
> 
>