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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.