On Tuesday 15 January 2002 21:21, David Brownell wrote:
> > > > I really doubt that this issue can be not exposed.
> > >
> > > And why is that? I just gave you an argument from first
> > > principles. You can't refute that by pointing to a bug in
> > > one current driver.
> >
> > Because all the HCD has is a pointer that may or may not be valid.
>
> Drivers that don't guarantee valid pointers have major defects.
> End of story. Debating it would be (more of a) a waste of my time.
>
> For example, it's not legit to use pointers after they've been kfreed,
> even if you're being well-intentioned and if it's done in another thread
> that you forgot to synchronize. That's just a bug, plain and simple,
> and it's not in the infrastructure code like kfree(). It's in your code
> that is passing around a pointer after its memory has been kfreed.
You _cannot_ even in principle synchronize between a completion
handler and process context. It's a one way street of communication.
That race is unavoidable.
If the driver must guarantee the validity of the pointer, freeing an
urb in its completion handler is undoable in principle.
How on earth are you supposed to kill an urb that is freed this way,
if you cannot use usb_unlink_urb ?
Which way do you want it ? Freeing in the completion handler or not ?
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
