Hi Ulisses, > >> > Changing socket lock to L2CAP chan lock in L2CAP code. Needed for implementing > >> > protocol above L2CAP without creating sockets. > >> > > >> > Changes: > >> > * RFCv6: Same code but patches 2,3 and 4 from RFCv5 are merged together > >> > following recommendations from review. > >> > * RFCv5: Fixed locking bug in l2cap_data_channel, added locks in > >> > l2cap_sock_shutdown function, fixed several styles issues. > >> > * RFCv4: Better split patches so they looks more clear and obvious, > >> > taking coments about naming change and delete unused vars. See diff change > >> > from the previous version below: > >> > * RFCv3: Split the big patch to several small (I believe logical) chunks, > >> > remove unneded locks from cleanup_listen, use the same arguments for > >> > locked/unlocked socket error functions. > >> > * RFCv2: Convert l2cap channel list back to mutex from RCU list. > >> > >> so what is the general status of this patch series. Are there still > >> concerns or opens? Or should it be go for final review and be merged? > > > > The code looks now good enough for final review. > > Marcel, the code looks good for final review and merge. The only thing > concerns me is the change to chan->lock instead of sock lock seems to > be split too much. I mean that we have this change done in a series of > patches while it might be better to change everything at once. Not > sure if worrying about intermediate states here is something you care > or not, though, because I'm almost sure they'll be broken doing it in > small pieces. I am fine either way at this point. > And IMO it'd be good if Padovan could take a look at the patches > moving to chan->lock as well. Then please add proper reviewed-by tags to the patches. Regards Marcel -- 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