> > I don't see what you're implying. Synchronous unlink in the
> > completion handler does not work, as a rule. So from the
> > perspective of the driver, which does an async unlink (only
> > relevant for a periodic URB), the URB is going to still be
> > linked until it gets a callback with "-E
> I don't see what you're implying. Synchronous unlink in the
> completion handler does not work, as a rule. So from the
> perspective of the driver, which does an async unlink (only
> relevant for a periodic URB), the URB is going to still be
> linked until it gets a callback with "-ECONNRESET"
> > Freeing an URB you own is always legal.
> >
> > Unlinking an URB that's not linked is a different issue.
(That "not" shouldn't have been there)
> > For the moment I don't want to confuse things by talking
> > about those cases.
>
> I don't think that you can seperate the issues.
I do,
On Monday 14 January 2002 20:20, David Brownell wrote:
> Freeing an URB you own is always legal.
>
> Unlinking an URB that's not linked is a different issue.
> For the moment I don't want to confuse things by talking
> about those cases.
I don't think that you can seperate the issues.
Either the
rownell" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, January 14, 2002 11:01 AM
Subject: Re: [linux-usb-devel] Re: two bugs in usb-skeleton
>
> > No can do. For control/bulk (and some periodic cases), that handler
> > may have freed the URB (and perhaps po
> No can do. For control/bulk (and some periodic cases), that handler
> may have freed the URB (and perhaps poisoned it). Even without
> being SMP, such memory could have been reused for something
> else by that point. (I've certainly seen that happen.) Such flags don't
> really even _exist_
> > > there's ALWAYS a race on SMPs between completion handler
> > > finishing with that URB, and other driver code reusing it.
> >
> that makes no sense.
Then think about it some more, until it does.
> In the isr, which calls the completion handler, the flag is _cleared_ /
> counter decremente
On Monday 14 January 2002 18:56, David Brownell wrote:
> My original description of the race was:
> > there's ALWAYS a race on SMPs between completion handler
> > finishing with that URB, and other driver code reusing it.
>
> In more detail, HCD code on some CPU will set the "flag" value,
> probab
TED]>
To: "David Brownell" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, January 14, 2002 1:11 AM
Subject: Re: [linux-usb-devel] Re: two bugs in usb-skeleton
> > An ISR would be part of the HCD ... so my earlier comments
> > apply. That can't wor
> An ISR would be part of the HCD ... so my earlier comments
> apply. That can't work. And the work doesn't actually need
> to be done in_irq(), fwiw.
>
> > Thus, doing it with a flag (and both the urb->dev and the
> > urb->status methods are effectively flags) is difficult
>
> "not possible" ..
On Sun, Jan 13, 2002 at 07:27:06PM -0800, David Brownell wrote:
> Simpler to just have completion handlers explicitly put urbs on
> lists when they're available for reuse.
In thinking more about this today, and looking at the code a bunch, I
now agree with this. I think I'll play around with the
> > No HCD could resolve that race, any more than other
> > parts of usbcore could, since it happens after the HCD
> > has given up ownership of the URB.
> >
> > >(or the completion handler could)
> >
> > ONLY completion handlers can do that. HCDs can't, as I
> > just explained above.
>
> O
On Sun, Jan 13, 2002 at 10:24:55AM -0800, Greg KH wrote:
> On Sun, Jan 13, 2002 at 12:58:45PM +0100, Oliver Neukum wrote:
> > 2) skel_write checks for -EINPROGRESS. This is a race.
>
> Yes, but it's a race that _so_ many different drivers have that I don't
> consider it a driver problem. It sho
> > Usbcore can't mark an URB as reusable.
> > Only the HCD can do that without a race
>
> In that context, that's what I meant. From the perspective of
> all drivers except "hub" or HCDs, "usbcore" includes/hides
> all the HCDs. They don't see HCDs, they talk to usbcore
> (which talks to the HC
> > But let me correct myself: even that's not good enough. Drivers
> > always need to explicitly manage URB reuse from completion
> > handlers ... if they expect usbcore to mark URBs as reusable,
> > there's ALWAYS a race on SMPs between completion handler
> > finishing with that URB, and other
> But let me correct myself: even that's not good enough. Drivers
> always need to explicitly manage URB reuse from completion
> handlers ... if they expect usbcore to mark URBs as reusable,
> there's ALWAYS a race on SMPs between completion handler
> finishing with that URB, and other driver c
> > I thought 2.4 already has a fix for this. The correct test here is
> > whether urb->dev is non-null, yes? Host controllers clear that
> > when they're really done with an URB.
>
> This is most subtle. IMHO too subtle.
It's a side effect of a fix for some related races, as I recall.
But
> I thought 2.4 already has a fix for this. The correct test here is
> whether urb->dev is non-null, yes? Host controllers clear that
> when they're really done with an URB.
>
> - Dave
This is most subtle. IMHO too subtle. Couldn't we have a clearly
named flag for that and kill EINPROGRESS ou
> > 2) skel_write checks for -EINPROGRESS. This is a race.
>
> Yes, but it's a race that _so_ many different drivers have that I don't
> consider it a driver problem. It should be fixed in the host controller
> and core, and not have every driver have to implement something like a
> "writing" fl
19 matches
Mail list logo
