Search Linux Wireless

Re: [PATCH] libertas: fix spinlock recursion bug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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.

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux