Re: [PATCH 2/4] Bluetooth: Rename _busy_wq to _l2cap_wq

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

 




On Thu, 9 Jun 2011, Gustavo F. Padovan wrote:

* Mat Martineau <mathewm@xxxxxxxxxxxxxx> [2011-06-08 16:24:05 -0700]:


On Mon, 6 Jun 2011, Gustavo F. Padovan wrote:

* Mat Martineau <mathewm@xxxxxxxxxxxxxx> [2011-06-03 16:21:08 -0700]:

This workqueue will be used for general L2CAP work, not just dealing
with "busy" frames.

which general L2CAP work are we talking about?

I'll update the commit message and resubmit, but to immediately
answer your question:

* ERTM tx queue callbacks (patch 3/4 in this series)
* ERTM timers (ack, retrans, monitor) that can utilize proper locking.

What are the problems with ERTM timers? From what I remember it was not using
reference count on them, I fixed this. Patch is on this mailing for review.

The ERTM timer handlers modify l2cap_chan data, but use bh_lock_sock() and bh_unlock_sock() instead of lock_sock() and release_sock(). The socket might be locked in userspace context, but these timers can fire and start executing code concurrently.

See http://article.gmane.org/gmane.linux.bluez.kernel/6808 for the full description.

With the refactoring of L2CAP to separate out the socket code, we will still need a per-channel lock to protect l2cap_chan data.

* Updating the ERTM tx queue after an AMP channel move and L2CAP
reconfiguration
* Moving various AMP-related work out of interrupt context

Marcel wrote a patch sometime ago the move the whole Bluetooth core work out
of the interrupt context. That will help with many issues we have today,
including these you are talking about.
We need to take that patch, fix it, and push it no bluetooth-next.
This task is on my TODO list, but my TODO list is getting bigger. ;)

This would be a big help, do you have a pointer to this patch? Is the new workqueue accessible for all Bluetooth modules, or is it just for the HCI core? The other issues in my list still need a workqueue to use, they are not solved by moving rx processing out of interrupt context. If rx processing gets rid of interrupt context, we'll also want to take a close look at all other timer use.

Thanks,

--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux