Hi,
...
They don't make that assumption (don't reference devices that way),
so they don't need to. So that change should be UHCI-specific.
You said that they rely on having a valid device pointer. They must do
reference counting then.
They never make a copy of urb->dev ... so they relying
In message <[EMAIL PROTECTED]> you write:
> In fact, going down the path of reference counting urbs, sk_buffs etc
> seems to me like a big mistake. It is never ending. For example, in
> the speedtouch driver I use a tasklet. Thus there is a callback into
> the module by the tasklet. The tasklet
On Tue, Feb 18, 2003 at 12:49:43PM -0500, Johannes Erdfelt wrote:
> On Tue, Feb 18, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Tue, Feb 18, 2003 at 12:24:49PM -0500, Johannes Erdfelt wrote:
> > > On Tue, Feb 18, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> > > > On Tue, Feb 18, 2003 at 08:59:15A
On Tue, Feb 18, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
> >>Seems like a UHCI-specific expectation, so it's UHCI that should
> >>be adding the extra reference count. (Rather than breaking the
> >>other HCDs, which just rely on the URB having a valid device ptr.)
> >
> > If they make that
Seems like a UHCI-specific expectation, so it's UHCI that should
be adding the extra reference count. (Rather than breaking the
other HCDs, which just rely on the URB having a valid device ptr.)
If they make that assumption too, then they should be using reference
counting too.
They don't mak
On Tue, Feb 18, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
> >>>In 2.4, uhci.c holds a reference to the device until after it's done
> >>>calling the completion handler.
> >>>
> >>>Now in 2.5, the hcd layer doesn't hold that reference anymore it seems.
> >>>
> >>>That should be fixed.
>
> See
In 2.4, uhci.c holds a reference to the device until after it's done
calling the completion handler.
Now in 2.5, the hcd layer doesn't hold that reference anymore it seems.
That should be fixed.
Seems like a UHCI-specific expectation, so it's UHCI that should
be adding the extra reference count
I'm trying to fix up the usb device reference counting
logic right now and running into issues where host controllers try to
access urbs after their devices have been removed from the system :(
Not supposed to happen ... when they call giveback(), that's supposed to
mean they've forgotten about
On Tue, Feb 18, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 18, 2003 at 12:24:49PM -0500, Johannes Erdfelt wrote:
> > On Tue, Feb 18, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> > > On Tue, Feb 18, 2003 at 08:59:15AM -0800, David Brownell wrote:
> > > > Not supposed to happen ... when the
On Tue, Feb 18, 2003 at 12:24:49PM -0500, Johannes Erdfelt wrote:
> On Tue, Feb 18, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Tue, Feb 18, 2003 at 08:59:15AM -0800, David Brownell wrote:
> > > Greg KH wrote:
> > > >
> > > >Yes, this is a problem, the module can be unloaded and then the
> > >
On Tue, Feb 18, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 18, 2003 at 08:59:15AM -0800, David Brownell wrote:
> > Greg KH wrote:
> > >
> > >Yes, this is a problem, the module can be unloaded and then the
> > >completion fuction can be called.
> >
> > How? I don't see it. Unless the
On Tue, Feb 18, 2003 at 08:59:15AM -0800, David Brownell wrote:
> Greg KH wrote:
> >
> >Yes, this is a problem, the module can be unloaded and then the
> >completion fuction can be called.
>
> How? I don't see it. Unless the driver completely violates
> basic rules like implementing disconnect()
Greg KH wrote:
Yes, this is a problem, the module can be unloaded and then the
completion fuction can be called.
How? I don't see it. Unless the driver completely violates
basic rules like implementing disconnect() correctly, which
will break more than just module unloading.
I'm trying to
> Yes, this is a problem, the module can be unloaded and then the
> completion fuction can be called.
If that happens your disconnect() is buggy independent of module
unload.
> I talked a lot with Rusty about this problem, and he insists that the
> new module reference counts are lightweight eno
> > Hi Oliver, I understand better now - both the new module subsystem and
> > how USB uses it. However, the USB subsystem should be doing
> > try_module_get before any call into a driver. But there is one case in
> > which it doesn't: calling urb completion handlers. Isn't this wrong?
>
> Yes,
Sorry for the late reply, catching up on old email.
On Fri, Feb 07, 2003 at 09:54:07PM +0100, Duncan Sands wrote:
> On Friday 07 February 2003 17:28, Oliver Neukum wrote:
> > > That was a guess - and it seems wrong (I should have taken the 30 seconds
> > > needed to check...). I can't in fact see
On Mon, 10 Feb 2003, Duncan Sands wrote:
> Yes, one advantage of a sync unlink is that you get an error code in case
> of failure which you may not get with an async unlink (for example because
> the urb never completes).
I think you've got that backward. If the urb never completes then the
syn
On Monday 10 February 2003 16:05, Alan Stern wrote:
> On Mon, 10 Feb 2003, Duncan Sands wrote:
> > > Depending on the usage model the driver follows, this might not be
> > > true. For instance, one commonly recommended theme is for the driver to
> > > increment its module-use-count each time it sub
Hi Alan, here are my immediate thoughts, which means I didn't check
whether what I say is true.
> To satisfy my curiousity, can you think of _any_ situation at all in which
> you would be better off doing a synchronous unlink instead of an async
> one, knowing that the synchronous call might retur
Alan Stern wrote:
On Sun, 9 Feb 2003, Duncan Sands wrote:
In that other driver structure, synchronizing on urb completions
after an (async) unlink failure would either (a) have succeeded,
because the "failure" was like the EBUSY case, "warp crystals
would explode if we unlinked any faster", or (
> Not necessarily, it depends on the structure of the driver. Increasing
> the use count in this way would prevent unloading while any urbs are in
> use, thus making it unnecessary to cancel anything in disconnect().
> (Unfortunately, that doesn't work out quite so nicely on SMP systems.)
No, th
On Sun, 9 Feb 2003, Duncan Sands wrote:
> > In that other driver structure, synchronizing on urb completions
> > after an (async) unlink failure would either (a) have succeeded,
> > because the "failure" was like the EBUSY case, "warp crystals
> > would explode if we unlinked any faster", or (b) f
On Mon, 10 Feb 2003, Duncan Sands wrote:
> > Depending on the usage model the driver follows, this might not be
> > true. For instance, one commonly recommended theme is for the driver to
> > increment its module-use-count each time it submits an urb and
> > decrement the count in the completion r
> Depending on the usage model the driver follows, this might not be
> true. For instance, one commonly recommended theme is for the driver to
> increment its module-use-count each time it submits an urb and
> decrement the count in the completion routine. When this approach is
> used, the kernel
> In that other driver structure, synchronizing on urb completions
> after an (async) unlink failure would either (a) have succeeded,
> because the "failure" was like the EBUSY case, "warp crystals
> would explode if we unlinked any faster", or (b) failed because
> of some HCD problem.
>
> Success
Duncan Sands wrote:
>
> Hi Dave, I'm still confused about how leaking memory can help.
The way you were phrasing your questions, the driver synchronized
on unlink success to determine when it was safe to free urb (and
maybe buffer). The error indicates synchronization failed ... so
the safest ass
> > Conclusion B: you must loop around retrying usb_unlink_urb until it
> > succeeds (if ever). Is that right?
>
> If usb_unlink_urb() actually fails, I truly doubt that it will ever
> succeed. So retrying is not likely to help at all. On the other hand,
> maybe it's not so bad to just sit aroun
On Sat, 8 Feb 2003, Duncan Sands wrote:
> Conclusion A: you must be sure
> to have unlinked all urbs before leaving the disconnect routine.
More accurately, you must be sure that all urbs have finished (their
completion handlers have been called) before leaving disconnect().
> Conclusion B: yo
> >>> Driver decides to follow Dave's
> >>> advice and leak memory in this error situation, so it doesn't
> >>> free its structures, and exits the disconnect method.
>
> The first part of the advice was equally important: log a message,
> so that eventually, in the unlikely case something bad
Oliver Neukum wrote:
However, the USB subsystem should be doing
try_module_get before any call into a driver. But there is one case in
which it doesn't: calling urb completion handlers. Isn't this wrong?
No. The driver's disconnect method is responsible for unlinking all URBs and
_wait_ for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Freitag, 7. Februar 2003 21:54 schrieb Duncan Sands:
> On Friday 07 February 2003 17:28, Oliver Neukum wrote:
> > > That was a guess - and it seems wrong (I should have taken the 30
> > > seconds needed to check...). I can't in fact see anything th
On Friday 07 February 2003 17:28, Oliver Neukum wrote:
> > That was a guess - and it seems wrong (I should have taken the 30 seconds
> > needed to check...). I can't in fact see anything that stops the module
> > being unloaded after a successful probe! I assumed that the driver would
>
> That's
Hi,
- probe function is called, driver is bound to an interface
- (driver cannot be unloaded now - this is done in sysfs, no?)
Just what does sysfs do here? So far as I am aware, it does nothing to
prevent the driver from being unloaded. And if it does do something, how
does the user tell it
Duncan:
My knowledge of sysfs is very sketchy, at best. I've read the stuff in
the Documentation directory, but I haven't looked at the code so I don't
know how it works in practice.
On Fri, 7 Feb 2003, Duncan Sands wrote:
> > > - driver (module) registers with USB subsystem
> > > - probe fun
> That was a guess - and it seems wrong (I should have taken the 30 seconds
> needed to check...). I can't in fact see anything that stops the module
> being unloaded after a successful probe! I assumed that the driver would
That's right. A driver can be unloaded even if it is bound to a device
Hi Alan,
On Friday 07 February 2003 16:20, Alan Stern wrote:
> I too would appreciate getting some good answers to these questions. My
> current understanding is limited (and quite likely wrong at some points).
>
> On Fri, 7 Feb 2003, Duncan Sands wrote:
> > It seems to me that the following is p
I too would appreciate getting some good answers to these questions. My
current understanding is limited (and quite likely wrong at some points).
On Fri, 7 Feb 2003, Duncan Sands wrote:
> It seems to me that the following is possible:
>
> - driver (module) registers with USB subsystem
> - prob
37 matches
Mail list logo
