* [PATCH] Bluetooth: Use non locking get_chan and explicit lock
@ 2012-01-20 11:50 Emeltchenko Andrei
2012-01-21 16:41 ` Marcel Holtmann
0 siblings, 1 reply; 4+ messages in thread
From: Emeltchenko Andrei @ 2012-01-20 11:50 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
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);
BT_DBG("chan %p, len %d", chan, skb->len);
@@ -4681,10 +4683,11 @@ int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 flags)
goto drop;
}
- chan = l2cap_get_chan_by_scid(conn, cid);
+ chan = __l2cap_get_chan_by_scid(conn, cid);
if (chan && chan->sk) {
struct sock *sk = chan->sk;
+ lock_sock(sk);
if (chan->imtu < len - L2CAP_HDR_SIZE) {
BT_ERR("Frame exceeding recv MTU (len %d, "
--
1.7.4.1
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH] Bluetooth: Use non locking get_chan and explicit lock
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
0 siblings, 1 reply; 4+ messages in thread
From: Marcel Holtmann @ 2012-01-21 16:41 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
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.
Regards
Marcel
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] Bluetooth: Use non locking get_chan and explicit lock
2012-01-21 16:41 ` Marcel Holtmann
@ 2012-01-23 8:33 ` Emeltchenko Andrei
2012-01-23 9:01 ` Marcel Holtmann
0 siblings, 1 reply; 4+ messages in thread
From: Emeltchenko Andrei @ 2012-01-23 8:33 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
Hi Marcel,
On Sat, Jan 21, 2012 at 05:41:34PM +0100, Marcel Holtmann wrote:
> 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<--------------------
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?
Best regards
Andrei Emeltchenko
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] Bluetooth: Use non locking get_chan and explicit lock
2012-01-23 8:33 ` Emeltchenko Andrei
@ 2012-01-23 9:01 ` Marcel Holtmann
0 siblings, 0 replies; 4+ messages in thread
From: Marcel Holtmann @ 2012-01-23 9:01 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-01-23 9:01 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 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).