Hi Mat, On Fri, May 4, 2012 at 6:54 PM, Mat Martineau <mathewm@xxxxxxxxxxxxxx> wrote: > > 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. Thanks, that's good to know. Regards, -- Ulisses Furquim ProFUSION embedded systems http://profusion.mobi Mobile: +55 19 9250 0942 Skype: ulissesffs -- 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