> > Having refcount mechanisms doesn't help when the basic
> > problem is keeping pointers around after they've become
> > invalid (for whatever reason).
>
> It helps with the underlying problem of "when can I reference this".
But it's not sufficient. You're still DOA if you try to do what
Oliver keeps talking about: accessing a pointer without using
the necessary locking against other execution contexts.
Nor in fact is it necessary.
if (!sufficent && !necessary) { ... }
> All the races reduce to harmless things
As would _also_ be true in these examples using a simpler
policy in the driver: protect access to that urb's pointer with a
spinlock, and null that pointer when it's freed. A lock to protect
access to the saved URB pointer is going to be necessary in
any case, just as with access to most shared mutable state.
Which isn't to say that a refcount mechanism doesn't help in
other cases, but nobody should think that it's either necessary
or sufficient to address the examples so far presented.
> People are struggling to get the drivers right,
Bugs also get fixed over time, including ones like accessing
data without the neccessary locking.
> and we haven't even got to
> the full party game of
>
> "I'm in my completion handler removing the urb while on cpu #2
> the irq handler might be running, cpu 3 someone is closing the
> device, cpu 4 is running a kernel thread oh and someone just
> hotplugged the cardbus controller the USB is on"
>
> lets face it - nobody is going to be able to work that out without clear
> referencing 8)
Aha, a new example!
Actually I know that can be handled correctly without refcounting,
but I'd agree that so long as drivers ignore rules about what's safe
to reference and when, it won't be.
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
