Re: [PATCH] libertas: fix spinlock recursion bug

[Dan Williams <dcbw@redhat.com>]

On Thu, 2008-03-27 at 12:57 +0100, Holger Schurig wrote:
> > The problem with using upld_buf (and therefore zero-copy in
> > the CF driver) is that you have no idea how long a read from
> > the card will really take, and what errors might happen during
> > the read from the card.
> 
> Yes, this can take a long time. And, BTW, I don't want to use 
> upld_buf.
> 
> 
> My idea is this:
> 
> > > struct lbs_event *lbs_get_free_event(struct lbs_private
> > > *priv);
> 
> This will take out an lbs_event from the event_free_list and 
> return it.
> Taking out has to be done under spinlock, but this is very fast.
> 
> Once the lbs_event is no longer in any of the two event list, 
> we "own" it and can handle it as long as we want, without the 
> need of an additional spinlock.
> 
> Then
> 
> > > void lbs_handle_event(struct lbs_private *priv, struct
> > > lbs_event *event);
> 
> would again take the spinlock, insert the event in the 
> event_list, and release the spinlock. Which again takes only a 
> short time.

well, if this is being done in lbs_thread() then the call from
lbs_get_free_event() is going to be right above lbs_handle_event()
anyway, so you might as well hold the spinlock over both, right?  I'm
just basing that assumption off the existing structure of lbs_thread(),
maybe you've re-ordered it a lot or something.

But it sounds OK.

Dan

> This approach can make receiption of command responses from card 
> zero-copy like, at least insofar the event processing is 
> considered. 
> 
> 
> 
> > I'd argue that the CF driver should also have an internal
> > buffer like the SDIO and USB drivers do, and then there's still
> > only one copy.
> 
> Yeah, but I can reduce easily to a 0-copy-scheme.
> 
> 
> I hope all of this sounds sane.
>