Hi Pete,
> > What's so bad about freeing inside a callback? When else
> > would most drivers have all the facts in hand, so they know
> > that they're done using a given URB? Inquiring minds ...
>
> Short answer is "too confusing". I am sure Dan did a due dilligence
> looking at code paths and
On Sat, May 19, 2001 at 11:59:29AM -0400, Pete Zaitcev wrote:
> > The lock saves the URB from parallel deletion in the unlink_urb-functions on
> > SMP. There is already a urb_list_lock that can do this globally, but
> > urb_list_lock has to be released before the completion to allow further
> > s
> From: Georg Acher <[EMAIL PROTECTED]>
> Date: Sat, 19 May 2001 15:54:39 +0200
>
> On Fri, May 18, 2001 at 08:26:48PM -0400, Dan Streetman wrote:
> > >Short answer is "too confusing". I am sure Dan did a due dilligence
> > >looking at code paths and yet he blew it (I would too...).
> > >The fact
On Fri, May 18, 2001 at 08:26:48PM -0400, Dan Streetman wrote:
> >Short answer is "too confusing". I am sure Dan did a due dilligence
> >looking at code paths and yet he blew it (I would too...).
> >The fact that the technique is unconventional does not help.
>
> I can't see why the urb's spinloc
On Fri, 18 May 2001, Pete Zaitcev wrote:
>On Fri, May 18, 2001 at 06:44:07AM -0700, David Brownell wrote:
>> What's so bad about freeing inside a callback? When else
>> would most drivers have all the facts in hand, so they know
>> that they're done using a given URB? Inquiring minds ...
>
>Sh
On Fri, May 18, 2001 at 06:44:07AM -0700, David Brownell wrote:
> What's so bad about freeing inside a callback? When else
> would most drivers have all the facts in hand, so they know
> that they're done using a given URB? Inquiring minds ...
Short answer is "too confusing". I am sure Dan did
> >Note that the FILL_*_URB() macros always re-init the
> >spinlock, so the "reuse this URB" path won't care if the
> >HC didn't drop the lock.
>
> Does that mean that the FILL_*_URB() macros *must* be called before
> resubmitting?
No, you can always manually init an urb if you do as well as
the
> Wow...I see how the urb->complete() could free the urb (and spinlock), but it's
> not necessarily always freeing it, right?
Any time the URB isn't still "owned" by the HCD, then
all bets are off w.r.t. what that memory is now used for.
> Wouldn't it be better to not allow freeing inside the c
B? Inquiring minds ...
>
>- Original Message -
>From: "Pete Zaitcev" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Cc: "Dan Streetman" <[EMAIL PROTECTED]>
>Sent: Thursday, May 17, 2001 11:44 PM
>Subject: Re: [linux-usb-devel] [patch] usb
Wow...I see how the urb->complete() could free the urb (and spinlock), but it's
not necessarily always freeing it, right?
Wouldn't it be better to not allow freeing inside the completion? Let a driver
do it in a BH?
Or am I still off the mark? ;-)
On Fri, 18 May 2001, Pete Zaitcev wrote:
>D
On Fri, 18 May 2001, David Brownell wrote:
>Bad patch. I've seen oopses when the completion routine
>frees the URB, and then usb-uhci tries to access that URB
>in order to spin_unlock(&urb->lock) ... it's nulled so that
>the HCD knows never to access urbs after they have been
>given back to the
ROTECTED]>
Cc: "Dan Streetman" <[EMAIL PROTECTED]>
Sent: Thursday, May 17, 2001 11:44 PM
Subject: Re: [linux-usb-devel] [patch] usb-uhci held spinlock
> Dan, the little gem that you quote belongs to David-B.
> I was shocked what I saw it too. However, I let it pass
> unch
Bad patch. I've seen oopses when the completion routine
frees the URB, and then usb-uhci tries to access that URB
in order to spin_unlock(&urb->lock) ... it's nulled so that
the HCD knows never to access urbs after they have been
given back to the device driver.
Note that the FILL_*_URB() macros
Dan, the little gem that you quote belongs to David-B.
I was shocked what I saw it too. However, I let it pass
unchallenged upon David's authority, just ranted loud
about idiotic API of USB (w.r.t. freeing inside a callback).
Here is the thread:
http://marc.theaimsgroup.com/?t=9858100971&w=2
14 matches
Mail list logo
