Re: [RFCv2 5/8] Bluetooth: Restore locking semantics when looking up L2CAP channels

[Mat Martineau <mathewm@codeaurora.org>]

Gustavo -

On Sun, 29 Apr 2012, Gustavo Padovan wrote:

> Hi Mat,
>
> * Mat Martineau <mathewm@codeaurora.org> [2012-04-27 16:50:52 -0700]:
>
>> As the comment for l2cap_get_chan_by_scid indicated, the function used
>> to return a locked socket.  The lock for the socket was acquired while
>> the channel list was also locked.
>>
>> When locking was moved over to the l2cap_chan structure, the channel
>> lock was no longer acquired with the channel list still locked.  This
>> made it possible for the l2cap_chan to be deleted after
>> conn->chan_lock was released but before l2cap_chan_lock was called.
>> Making the call to l2cap_chan_lock before releasing conn->chan_lock
>> makes it impossible for the l2cap_chan to be deleted at the wrong
>> time.
>>
>> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
>> ---
>>  net/bluetooth/l2cap_core.c |   10 +++-------
>>  1 file changed, 3 insertions(+), 7 deletions(-)
>
> Applied to bluetooth-next. Thanks.

Please revert this for now.  This patch causes a locking imbalance if 
patch 4/8 is not merged first, and is the main reason I requested that 
*none* of these patches be merged yet in my cover letter message.

Thanks,

--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum