Hi Ulisses -
On Fri, 4 May 2012, Ulisses Furquim wrote:
Hi Mat,
On Wed, May 2, 2012 at 1:42 PM, Mat Martineau <mathewm@xxxxxxxxxxxxxx> wrote:
The ERTM and streaming mode transmit queue must only be accessed while
the L2CAP channel lock is held. Locking the channel before calling
l2cap_chan_send ensures that multiple threads cannot simultaneously
manipulate the queue when sending and receiving concurrently.
L2CAP channel locking had previously moved to the l2cap_chan struct
instead of the associated socket, so some of the old socket locking
can also be removed in this patch.
Signed-off-by: Mat Martineau <mathewm@xxxxxxxxxxxxxx>
---
include/net/bluetooth/bluetooth.h | 2 --
net/bluetooth/l2cap_sock.c | 15 ++++++++-------
2 files changed, 8 insertions(+), 9 deletions(-)
Looks good. I'm just wondering if we still have issues with chan lock
versus sock lock elsewhere. Maybe you've done some auditing of this?
I did an extensive review of the locking code with respect to ERTM
last week, and I'm satisfied with the use of chan_lock there.
The work to decouple l2cap_chan from sockets is not yet complete, so
there are still socket locking calls at connect and disconnect time.
The data path looks like it is clear of socket locks now.
--
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
