From: Marcel Holtmann <marcel@holtmann.org>
To: Ulisses Furquim <ulisses@profusion.mobi>
Cc: Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com>,
linux-bluetooth@vger.kernel.org
Subject: Re: [RFCv6 00/14] Bluetooth: Change socket lock to l2cap_chan lock
Date: Mon, 20 Feb 2012 15:53:14 +0100 [thread overview]
Message-ID: <1329749594.2172.2.camel@aeonflux> (raw)
In-Reply-To: <CAA37ikaRSnvSYXgDDh7mviFwSC2Ex=XoDLQ8JfBfNwEgwTxBaQ@mail.gmail.com>
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
next prev parent reply other threads:[~2012-02-20 14:53 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-20 14:21 [RFCv6 00/14] Bluetooth: Change socket lock to l2cap_chan lock Emeltchenko Andrei
2012-02-20 14:21 ` [RFCv6 01/14] Bluetooth: trivial: Fix long line Emeltchenko Andrei
2012-02-20 16:38 ` Gustavo Padovan
2012-02-20 14:21 ` [RFCv6 02/14] Bluetooth: Revert to mutexes from RCU list Emeltchenko Andrei
2012-02-20 14:44 ` Ulisses Furquim
2012-02-20 18:33 ` Gustavo Padovan
2012-02-20 18:57 ` Ulisses Furquim
2012-02-20 22:46 ` Gustavo Padovan
2012-02-20 14:21 ` [RFCv6 03/14] Bluetooth: Add l2cap_chan_lock Emeltchenko Andrei
2012-02-20 14:21 ` [RFCv6 04/14] Bluetooth: Add locked and unlocked state_change Emeltchenko Andrei
2012-02-20 14:21 ` [RFCv6 05/14] Bluetooth: Add socket error function Emeltchenko Andrei
2012-02-20 14:21 ` [RFCv6 06/14] Bluetooth: Add unlocked __l2cap_chan_add function Emeltchenko Andrei
2012-02-20 14:21 ` [RFCv6 07/14] Bluetooth: Use chan lock in timers Emeltchenko Andrei
2012-02-20 14:21 ` [RFCv6 08/14] Bluetooth: Use chan lock in L2CAP sig commands Emeltchenko Andrei
2012-02-20 14:21 ` [RFCv6 09/14] Bluetooth: Use chan lock in L2CAP conn start Emeltchenko Andrei
2012-02-20 14:21 ` [RFCv6 10/14] Bluetooth: Use chan lock in receiving data Emeltchenko Andrei
2012-02-20 14:21 ` [RFCv6 11/14] Bluetooth: Change locking logic for conn/chan ready Emeltchenko Andrei
2012-02-20 14:21 ` [RFCv6 12/14] Bluetooth: Change locking logic in security_cfm Emeltchenko Andrei
2012-02-20 14:21 ` [RFCv6 13/14] Bluetooth: Use l2cap chan lock in socket connect Emeltchenko Andrei
2012-02-20 14:21 ` [RFCv6 14/14] Bluetooth: Remove socket lock check Emeltchenko Andrei
2012-02-20 14:29 ` [RFCv6 00/14] Bluetooth: Change socket lock to l2cap_chan lock Marcel Holtmann
2012-02-20 14:44 ` Emeltchenko Andrei
2012-02-20 14:52 ` Ulisses Furquim
2012-02-20 14:53 ` Marcel Holtmann [this message]
2012-02-21 10:57 ` Emeltchenko Andrei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1329749594.2172.2.camel@aeonflux \
--to=marcel@holtmann.org \
--cc=Andrei.Emeltchenko.news@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=ulisses@profusion.mobi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).