From: Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com>
To: Ulisses Furquim <ulisses@profusion.mobi>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [RFCv4 02/16] Bluetooth: Revert to mutexes from RCU list
Date: Wed, 15 Feb 2012 10:16:53 +0200 [thread overview]
Message-ID: <20120215081650.GA920@aemeltch-MOBL1> (raw)
In-Reply-To: <CAA37ikY1=K0E+zXtsHO+FRWRK=VEfR99btVBENw_cJEhonfJvw@mail.gmail.com>
Hi Ulisses,
On Tue, Feb 14, 2012 at 03:23:54PM -0200, Ulisses Furquim wrote:
> On Tue, Feb 14, 2012 at 11:21 AM, Emeltchenko Andrei
> <Andrei.Emeltchenko.news@gmail.com> wrote:
> > Hi Ulisses,
> >
> > On Mon, Feb 13, 2012 at 10:06:10PM -0300, Ulisses Furquim wrote:
> > ...
> >> Yes, I do think they belong together. And please, check l2cap_sock.c
> >> where l2cap_chan_close() seems to be called without locking
> >> conn->chan_lock in l2cap_sock_shutdown().
> >
> > In that context we do not always have l2cap_conn so maybe we return
> > chan list lock to chan_del or invent unlocked chan_del / chan_close?
>
> We don't have l2cap_conn? So are we already on conn->chan_l list or
> not? Maybe it's better to check that instead of changing everything
> now.
I am afraid that the logic in l2cap_chan_close is a bit complicated, for
listening socket is recursively invokes itself for every sk in accept
queue. conn is created when connection is established, before that chan is
added only to global chan list. So if there is no connection we cannot get
lock in conn->chan_lock.
I believe that it is better to keep locking inside of chan_del.
Best regards
Andrei Emeltchenko
next prev parent reply other threads:[~2012-02-15 8:16 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-10 13:54 [RFCv4 00/16] Bluetooth: Change socket lock to l2cap_chan lock Emeltchenko Andrei
2012-02-10 13:54 ` [RFCv4 01/16] Bluetooth: trivial: Fix long line Emeltchenko Andrei
2012-02-10 13:54 ` [RFCv4 02/16] Bluetooth: Revert to mutexes from RCU list Emeltchenko Andrei
2012-02-10 18:24 ` Ulisses Furquim
2012-02-13 8:58 ` Emeltchenko Andrei
2012-02-13 14:49 ` Emeltchenko Andrei
2012-02-14 1:06 ` Ulisses Furquim
2012-02-14 13:21 ` Emeltchenko Andrei
2012-02-14 17:23 ` Ulisses Furquim
2012-02-15 8:16 ` Emeltchenko Andrei [this message]
2012-02-15 9:24 ` Emeltchenko Andrei
2012-02-15 17:26 ` Ulisses Furquim
2012-02-10 13:55 ` [RFCv4 03/16] Bluetooth: Do not use sk lock in get_chan functions Emeltchenko Andrei
2012-02-10 13:55 ` [RFCv4 04/16] Bluetooth: Add l2cap_chan_lock Emeltchenko Andrei
2012-02-10 13:55 ` [RFCv4 05/16] Bluetooth: Add locked and unlocked state_change Emeltchenko Andrei
2012-02-10 13:55 ` [RFCv4 06/16] Bluetooth: Add socket error function Emeltchenko Andrei
2012-02-14 18:39 ` Gustavo Padovan
2012-02-15 8:21 ` Emeltchenko Andrei
2012-02-10 13:55 ` [RFCv4 07/16] Bluetooth: Add unlocked __l2cap_chan_add function Emeltchenko Andrei
2012-02-10 13:55 ` [RFCv4 08/16] Bluetooth: Use chan lock in timers Emeltchenko Andrei
2012-02-10 13:55 ` [RFCv4 09/16] Bluetooth: Use chan lock in L2CAP sig commands Emeltchenko Andrei
2012-02-10 13:55 ` [RFCv4 10/16] Bluetooth: Use chan lock in chan delete functions Emeltchenko Andrei
2012-02-10 13:55 ` [RFCv4 11/16] Bluetooth: Use chan lock in L2CAP conn start Emeltchenko Andrei
2012-02-10 13:55 ` [RFCv4 12/16] Bluetooth: Use chan lock in receiving data Emeltchenko Andrei
2012-02-10 13:55 ` [RFCv4 13/16] Bluetooth: Change locking logic for conn/chan ready Emeltchenko Andrei
2012-02-10 13:55 ` [RFCv4 14/16] Bluetooth: Change locking logic in security_cfm Emeltchenko Andrei
2012-02-10 13:55 ` [RFCv4 15/16] Bluetooth: Use l2cap chan lock in socket connect Emeltchenko Andrei
2012-02-10 13:55 ` [RFCv4 16/16] Bluetooth: Remove socket lock check 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=20120215081650.GA920@aemeltch-MOBL1 \
--to=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).