From: Marcel Holtmann <marcel@holtmann.org>
To: Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH] Bluetooth: Use non locking get_chan and explicit lock
Date: Mon, 23 Jan 2012 10:01:29 +0100 [thread overview]
Message-ID: <1327309289.1955.85.camel@aeonflux> (raw)
In-Reply-To: <20120123083342.GA6214@aemeltch-MOBL1>
Hi Andrei,
> > > For receiving ACL packets use __l2cap_get_chan_by_scid which is not
> > > locking sk and explicitly lock sk after checking that it is exist.
> > > Code looks nicer since now it is surrounded by lock/release.
> > >
> > > Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> > > ---
> > > net/bluetooth/l2cap_core.c | 7 +++++--
> > > 1 files changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> > > index d16ad49..53dbfd3 100644
> > > --- a/net/bluetooth/l2cap_core.c
> > > +++ b/net/bluetooth/l2cap_core.c
> > > @@ -4243,7 +4243,7 @@ static inline int l2cap_data_channel(struct l2cap_conn *conn, u16 cid, struct sk
> > > u16 tx_seq;
> > > int len;
> > >
> > > - chan = l2cap_get_chan_by_scid(conn, cid);
> > > + chan = __l2cap_get_chan_by_scid(conn, cid);
> > > if (!chan) {
> > > if (cid == L2CAP_CID_A2MP) {
> > > chan = a2mp_channel_create(conn, skb);
> > > @@ -4255,6 +4255,8 @@ static inline int l2cap_data_channel(struct l2cap_conn *conn, u16 cid, struct sk
> > > }
> > >
> > > sk = chan->sk;
> > > + if (sk)
> > > + lock_sock(sk);
> >
> > this is the part I clearly do not like. This is pretty nasty conditional
> > locking. We need to figure out something better.
>
> Actually l2cap_data_channel function ends with:
>
> <------8<--------------------
> | if (sk)
> | release_sock(sk);
> |
> <------8<--------------------
that one slipped past me :(
> So in _this_ case it looks consistent. But I agree that generally it does
> not looks nice. The reason for that is l2cap_chan is locked with socket
> lock. Maybe we could create mutex l2cap_lock and functions like
> lock_chan(chan) / unlock_chan(chan) and change socket locks in l2cap_core
> with these new locks?
I agree. Lets see what happens if we lock l2cap_chan with its own lock.
Regards
Marcel
prev parent reply other threads:[~2012-01-23 9:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-20 11:50 [PATCH] Bluetooth: Use non locking get_chan and explicit lock Emeltchenko Andrei
2012-01-21 16:41 ` Marcel Holtmann
2012-01-23 8:33 ` Emeltchenko Andrei
2012-01-23 9:01 ` Marcel Holtmann [this message]
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=1327309289.1955.85.camel@aeonflux \
--to=marcel@holtmann.org \
--cc=Andrei.Emeltchenko.news@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
/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).