Re: [PATCH 3/4] Bluetooth: Lock the L2CAP channel when sending

[Mat Martineau <mathewm@codeaurora.org>]

Hi Ulisses -

On Fri, 4 May 2012, Ulisses Furquim wrote:

> Hi Mat,
>
> On Wed, May 2, 2012 at 1:42 PM, Mat Martineau <mathewm@codeaurora.org> 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@codeaurora.org>
>> ---
>>  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