* [PATCH 01/16] Bluetooth: Add src and dst info to struct l2cap_chan
From: Gustavo Padovan @ 2013-01-10 7:47 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Gustavo Padovan
In-Reply-To: <1357804073-31582-1-git-send-email-gustavo@padovan.org>
From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Adding these two info to l2cap_chan makes the l2cap_core.c a little more
independent of the struct sock.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
---
include/net/bluetooth/l2cap.h | 3 +++
net/bluetooth/l2cap_core.c | 46 ++++++++++++++++++-------------------------
net/bluetooth/l2cap_sock.c | 6 +++---
net/bluetooth/rfcomm/core.c | 15 +++++++-------
4 files changed, 33 insertions(+), 37 deletions(-)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index cdd3302..6040743 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -435,6 +435,9 @@ struct l2cap_seq_list {
struct l2cap_chan {
struct sock *sk;
+ bdaddr_t src;
+ bdaddr_t dst;
+
struct l2cap_conn *conn;
struct hci_conn *hs_hcon;
struct hci_chan *hs_hchan;
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 82a3bdc..ae51965 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -148,7 +148,7 @@ static struct l2cap_chan *__l2cap_global_chan_by_addr(__le16 psm, bdaddr_t *src)
struct l2cap_chan *c;
list_for_each_entry(c, &chan_list, global_l) {
- if (c->sport == psm && !bacmp(&bt_sk(c->sk)->src, src))
+ if (c->sport == psm && !bacmp(&c->src, src))
return c;
}
return NULL;
@@ -1305,7 +1305,6 @@ static struct l2cap_chan *l2cap_global_chan_by_scid(int state, u16 cid,
read_lock(&chan_list_lock);
list_for_each_entry(c, &chan_list, global_l) {
- struct sock *sk = c->sk;
if (state && c->state != state)
continue;
@@ -1315,16 +1314,16 @@ static struct l2cap_chan *l2cap_global_chan_by_scid(int state, u16 cid,
int src_any, dst_any;
/* Exact match. */
- src_match = !bacmp(&bt_sk(sk)->src, src);
- dst_match = !bacmp(&bt_sk(sk)->dst, dst);
+ src_match = !bacmp(&c->src, src);
+ dst_match = !bacmp(&c->dst, dst);
if (src_match && dst_match) {
read_unlock(&chan_list_lock);
return c;
}
/* Closest match */
- src_any = !bacmp(&bt_sk(sk)->src, BDADDR_ANY);
- dst_any = !bacmp(&bt_sk(sk)->dst, BDADDR_ANY);
+ src_any = !bacmp(&c->src, BDADDR_ANY);
+ dst_any = !bacmp(&c->dst, BDADDR_ANY);
if ((src_match && dst_any) || (src_any && dst_match) ||
(src_any && dst_any))
c1 = c;
@@ -1338,7 +1337,7 @@ static struct l2cap_chan *l2cap_global_chan_by_scid(int state, u16 cid,
static void l2cap_le_conn_ready(struct l2cap_conn *conn)
{
- struct sock *parent, *sk;
+ struct sock *parent;
struct l2cap_chan *chan, *pchan;
BT_DBG("");
@@ -1357,13 +1356,11 @@ static void l2cap_le_conn_ready(struct l2cap_conn *conn)
if (!chan)
goto clean;
- sk = chan->sk;
-
hci_conn_hold(conn->hcon);
conn->hcon->disc_timeout = HCI_DISCONN_TIMEOUT;
- bacpy(&bt_sk(sk)->src, conn->src);
- bacpy(&bt_sk(sk)->dst, conn->dst);
+ bacpy(&chan->src, conn->src);
+ bacpy(&chan->dst, conn->dst);
l2cap_chan_add(conn, chan);
@@ -1572,7 +1569,6 @@ static struct l2cap_chan *l2cap_global_chan_by_psm(int state, __le16 psm,
read_lock(&chan_list_lock);
list_for_each_entry(c, &chan_list, global_l) {
- struct sock *sk = c->sk;
if (state && c->state != state)
continue;
@@ -1582,16 +1578,16 @@ static struct l2cap_chan *l2cap_global_chan_by_psm(int state, __le16 psm,
int src_any, dst_any;
/* Exact match. */
- src_match = !bacmp(&bt_sk(sk)->src, src);
- dst_match = !bacmp(&bt_sk(sk)->dst, dst);
+ src_match = !bacmp(&c->src, src);
+ dst_match = !bacmp(&c->dst, dst);
if (src_match && dst_match) {
read_unlock(&chan_list_lock);
return c;
}
/* Closest match */
- src_any = !bacmp(&bt_sk(sk)->src, BDADDR_ANY);
- dst_any = !bacmp(&bt_sk(sk)->dst, BDADDR_ANY);
+ src_any = !bacmp(&c->src, BDADDR_ANY);
+ dst_any = !bacmp(&c->dst, BDADDR_ANY);
if ((src_match && dst_any) || (src_any && dst_match) ||
(src_any && dst_any))
c1 = c;
@@ -1607,7 +1603,7 @@ int l2cap_chan_connect(struct l2cap_chan *chan, __le16 psm, u16 cid,
bdaddr_t *dst, u8 dst_type)
{
struct sock *sk = chan->sk;
- bdaddr_t *src = &bt_sk(sk)->src;
+ bdaddr_t *src = &chan->src;
struct l2cap_conn *conn;
struct hci_conn *hcon;
struct hci_dev *hdev;
@@ -1674,9 +1670,7 @@ int l2cap_chan_connect(struct l2cap_chan *chan, __le16 psm, u16 cid,
}
/* Set destination address and psm */
- lock_sock(sk);
- bacpy(&bt_sk(sk)->dst, dst);
- release_sock(sk);
+ bacpy(&chan->dst, dst);
chan->psm = psm;
chan->dcid = cid;
@@ -3637,8 +3631,8 @@ static struct l2cap_chan *l2cap_connect(struct l2cap_conn *conn,
hci_conn_hold(conn->hcon);
- bacpy(&bt_sk(sk)->src, conn->src);
- bacpy(&bt_sk(sk)->dst, conn->dst);
+ bacpy(&chan->src, conn->src);
+ bacpy(&chan->dst, conn->dst);
chan->psm = psm;
chan->dcid = scid;
chan->local_amp_id = amp_id;
@@ -6274,17 +6268,16 @@ int l2cap_connect_ind(struct hci_dev *hdev, bdaddr_t *bdaddr)
/* Find listening sockets and check their link_mode */
read_lock(&chan_list_lock);
list_for_each_entry(c, &chan_list, global_l) {
- struct sock *sk = c->sk;
if (c->state != BT_LISTEN)
continue;
- if (!bacmp(&bt_sk(sk)->src, &hdev->bdaddr)) {
+ if (!bacmp(&c->src, &hdev->bdaddr)) {
lm1 |= HCI_LM_ACCEPT;
if (test_bit(FLAG_ROLE_SWITCH, &c->flags))
lm1 |= HCI_LM_MASTER;
exact++;
- } else if (!bacmp(&bt_sk(sk)->src, BDADDR_ANY)) {
+ } else if (!bacmp(&c->src, BDADDR_ANY)) {
lm2 |= HCI_LM_ACCEPT;
if (test_bit(FLAG_ROLE_SWITCH, &c->flags))
lm2 |= HCI_LM_MASTER;
@@ -6568,10 +6561,9 @@ static int l2cap_debugfs_show(struct seq_file *f, void *p)
read_lock(&chan_list_lock);
list_for_each_entry(c, &chan_list, global_l) {
- struct sock *sk = c->sk;
seq_printf(f, "%pMR %pMR %d %d 0x%4.4x 0x%4.4x %d %d %d %d\n",
- &bt_sk(sk)->src, &bt_sk(sk)->dst,
+ &c->src, &c->dst,
c->state, __le16_to_cpu(c->psm),
c->scid, c->dcid, c->imtu, c->omtu,
c->sec_level, c->mode);
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 1bcfb84..0977966 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -97,7 +97,7 @@ static int l2cap_sock_bind(struct socket *sock, struct sockaddr *addr, int alen)
__le16_to_cpu(la.l2_psm) == L2CAP_PSM_RFCOMM)
chan->sec_level = BT_SECURITY_SDP;
- bacpy(&bt_sk(sk)->src, &la.l2_bdaddr);
+ bacpy(&chan->src, &la.l2_bdaddr);
chan->state = BT_BOUND;
sk->sk_state = BT_BOUND;
@@ -259,11 +259,11 @@ static int l2cap_sock_getname(struct socket *sock, struct sockaddr *addr,
if (peer) {
la->l2_psm = chan->psm;
- bacpy(&la->l2_bdaddr, &bt_sk(sk)->dst);
+ bacpy(&la->l2_bdaddr, &chan->dst);
la->l2_cid = cpu_to_le16(chan->dcid);
} else {
la->l2_psm = chan->sport;
- bacpy(&la->l2_bdaddr, &bt_sk(sk)->src);
+ bacpy(&la->l2_bdaddr, &chan->src);
la->l2_cid = cpu_to_le16(chan->scid);
}
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index 201fdf7..15dc078 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -632,13 +632,13 @@ static struct rfcomm_session *rfcomm_session_get(bdaddr_t *src, bdaddr_t *dst)
{
struct rfcomm_session *s;
struct list_head *p, *n;
- struct bt_sock *sk;
+ struct l2cap_chan *chan;
list_for_each_safe(p, n, &session_list) {
s = list_entry(p, struct rfcomm_session, list);
- sk = bt_sk(s->sock->sk);
+ chan = l2cap_pi(s->sock->sk)->chan;
- if ((!bacmp(src, BDADDR_ANY) || !bacmp(&sk->src, src)) &&
- !bacmp(&sk->dst, dst))
+ if ((!bacmp(src, BDADDR_ANY) || !bacmp(&chan->src, src)) &&
+ !bacmp(&chan->dst, dst))
return s;
}
return NULL;
@@ -727,9 +727,9 @@ void rfcomm_session_getaddr(struct rfcomm_session *s, bdaddr_t *src, bdaddr_t *d
{
struct sock *sk = s->sock->sk;
if (src)
- bacpy(src, &bt_sk(sk)->src);
+ bacpy(src, &l2cap_pi(sk)->chan->src);
if (dst)
- bacpy(dst, &bt_sk(sk)->dst);
+ bacpy(dst, &l2cap_pi(sk)->chan->dst);
}
/* ---- RFCOMM frame sending ---- */
@@ -2126,7 +2126,8 @@ static int rfcomm_dlc_debugfs_show(struct seq_file *f, void *x)
struct sock *sk = s->sock->sk;
seq_printf(f, "%pMR %pMR %ld %d %d %d %d\n",
- &bt_sk(sk)->src, &bt_sk(sk)->dst,
+ &l2cap_pi(sk)->chan->src,
+ &l2cap_pi(sk)->chan->dst,
d->state, d->dlci, d->mtu,
d->rx_credits, d->tx_credits);
}
--
1.8.0.2
^ permalink raw reply related
* [PATCH 00/16] Completely remove socket dependency from l2cap_core.c
From: Gustavo Padovan @ 2013-01-10 7:47 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Gustavo Padovan
From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
This is the last series of patches to completely remove the l2cap socket usage
in the l2cap_core.c file. We now have a C API to access L2CAP and as a next
step we should convert RFCOMM to use this API.
Gustavo Padovan (16):
Bluetooth: Add src and dst info to struct l2cap_chan
Bluetooth: Remove sk_sndtimeo from l2cap_core.c
Bluetooth: extend state_change() call to report errors too
Bluetooth: add l2cap_state_change_and_error()
Bluetooth: Add missing braces to an "else if"
Bluetooth: use l2cap_chan_ready() instead of duplicate code
Bluetooth: duplicate DEFER_SETUP flag on l2cap_chan
Bluetooth: Improving locking in l2cap_conn_start()
Bluetooth: lock socket in defer_cb call
Bluetooth: Remove socket lock from state_change() in l2cap_core
Bluetooth: remove parent socket usage from l2cap_core.c
Bluetooth: Use abstract chan->data in comparison
Bluetooth: Move l2cap_wait_ack() to l2cap_sock.c
Bluetooth: Create l2cap->ops->resume()
Bluetooth: Create l2cap->ops->set_shutdown()
Bluetooth: Remove sk member from struct l2cap_chan
include/net/bluetooth/l2cap.h | 22 ++++-
net/bluetooth/a2mp.c | 4 +-
net/bluetooth/l2cap_core.c | 200 ++++++++++++------------------------------
net/bluetooth/l2cap_sock.c | 96 +++++++++++++++++---
net/bluetooth/rfcomm/core.c | 15 ++--
5 files changed, 169 insertions(+), 168 deletions(-)
--
1.8.0.2
^ permalink raw reply
* pull request: bluetooth 2013-01-10
From: Gustavo Padovan @ 2013-01-10 7:34 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, linux-bluetooth, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]
Hi John,
A few fixes for 3.8. Five of them are just new devices ids addition.
Apart from the that there is fix to a kernel memory leak to userspace from
Anderson Lizardo, two interoperability fixes from Jaganath Kanakkassery and
Szymon Janc. And a crash fix by me.
Please pull, or let me know of any problem with these patches. Thanks.
Gustavo
--
The following changes since commit 5e20a4b53094651d80f856ff55a916b999dbb57a:
b43: Fix firmware loading when driver is built into the kernel (2013-01-07 14:34:45 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth master
for you to fetch changes up to b7e98b5100aad9290d7f06fcb9d1e80f7f62f05f:
Bluetooth: Check if the hci connection exists in SCO shutdown (2013-01-10 03:53:32 -0200)
----------------------------------------------------------------
AceLan Kao (3):
Bluetooth: Add support for IMC Networks [13d3:3393]
Bluetooth: Add support for Foxconn / Hon Hai [0489:e04e]
Bluetooth: Add support for Foxconn / Hon Hai [0489:e056]
Anderson Lizardo (1):
Bluetooth: Fix incorrect strncpy() in hidp_setup_hid()
Daniel Schaal (1):
Bluetooth: Add support for GC-WB300D PCIe [04ca:3006] to ath3k.
Gustavo Padovan (1):
Bluetooth: Check if the hci connection exists in SCO shutdown
Jaganath Kanakkassery (1):
Bluetooth: Fix authentication if acl data comes before remote feature evt
Sergio Cambra (1):
Bluetooth device 04ca:3008 should use ath3k
Szymon Janc (1):
Bluetooth: Fix sending HCI commands after reset
drivers/bluetooth/ath3k.c | 10 ++++++++++
drivers/bluetooth/btusb.c | 5 +++++
net/bluetooth/hci_core.c | 8 --------
net/bluetooth/hci_event.c | 2 +-
net/bluetooth/hidp/core.c | 2 +-
net/bluetooth/l2cap_core.c | 11 +++++++++++
net/bluetooth/sco.c | 2 +-
7 files changed, 29 insertions(+), 11 deletions(-)
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] Bluetooth device 04ca:3008 should use ath3k
From: Sergio Cambra @ 2013-01-10 7:20 UTC (permalink / raw)
To: Gustavo Padovan, linux-bluetooth
In-Reply-To: <20130110051709.GC18821@joana>
Great, thanks
On Jueves, 10 de enero de 2013 03:17:09 Gustavo Padovan escribió:
> Hi Sergio,
>
> * Sergio Cambra <sergio@enpijama.es> [2013-01-10 01:06:55 +0100]:
> > From: Sergio Cambra <sergio@programatica.es>
> >
> > Output of /sys/kernel/debug/usb/devices
> > T: Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 6 Spd=12 MxCh= 0
> > D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> > P: Vendor=04ca ProdID=3008 Rev= 0.02
> > C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
> > I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> > E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
> > E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> > E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> > I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> > E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> > E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> > I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> > E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> > E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> > I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> > E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> > E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> > I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> > E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> > E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> > I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> > E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> > E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> > I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> > E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
> > E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
> >
> > Signed-off-by: Sergio Cambra <sergio@programatica.es>
> > ---
> >
> > drivers/bluetooth/ath3k.c | 2 ++
> > drivers/bluetooth/btusb.c | 1 +
> > 2 files changed, 3 insertions(+)
>
> Patch has been applied to bluetooth.git. Thanks.
>
> Gustavo
^ permalink raw reply
* Re: [PATCH v1] Bluetooth: Fix authentication if acl data comes before remote feature evt
From: Gustavo Padovan @ 2013-01-10 7:08 UTC (permalink / raw)
To: Jaganath Kanakkassery; +Cc: linux-bluetooth
In-Reply-To: <1357793915-6101-1-git-send-email-jaganath.k@samsung.com>
Hi Jaganath,
* Jaganath Kanakkassery <jaganath.k@samsung.com> [2013-01-10 10:28:35 +0530]:
> If remote device sends l2cap info request before read_remote_ext_feature
> completes then mgmt_connected will be sent in hci_acldata_packet() and
> remote name request wont be sent and eventually authentication wont happen
>
> Hcidump log of the issue
>
> < HCI Command: Create Connection (0x01|0x0005) plen 13
> bdaddr BC:85:1F:74:7F:29 ptype 0xcc18 rswitch 0x01 clkoffset 0x4bf7 (valid)
> Packet type: DM1 DM3 DM5 DH1 DH3 DH5
> > HCI Event: Command Status (0x0f) plen 4
> Create Connection (0x01|0x0005) status 0x00 ncmd 1
> > HCI Event: Connect Complete (0x03) plen 11
> status 0x00 handle 12 bdaddr BC:85:1F:74:7F:29 type ACL encrypt 0x00
> < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
> handle 12
> > HCI Event: Command Status (0x0f) plen 4
> Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
> > HCI Event: Read Remote Supported Features (0x0b) plen 11
> status 0x00 handle 12
> Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
> > HCI Event: Max Slots Change (0x1b) plen 3
> handle 12 slots 5
> < HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3
> handle 12 page 1
> > HCI Event: Command Status (0x0f) plen 4
> Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
> > ACL data: handle 12 flags 0x02 dlen 10
> L2CAP(s): Info req: type 2
> < ACL data: handle 12 flags 0x00 dlen 16
> L2CAP(s): Info rsp: type 2 result 0
> Extended feature mask 0x00b8
> Enhanced Retransmission mode
> Streaming mode
> FCS Option
> Fixed Channels
> > HCI Event: Read Remote Extended Features (0x23) plen 13
> status 0x00 handle 12 page 1 max 1
> Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> > ACL data: handle 12 flags 0x02 dlen 10
> L2CAP(s): Info req: type 3
> < ACL data: handle 12 flags 0x00 dlen 20
> L2CAP(s): Info rsp: type 3 result 0
> Fixed channel list 0x00000002
> L2CAP Signalling Channel
> > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 12 packets 2
>
> This patch moves sending mgmt_connected from hci_acldata_packet() to
> l2cap_connect_req() since this code is to handle the scenario remote
> device sends l2cap connect req too fast
>
> Signed-off-by: Jaganath Kanakkassery <jaganath.k@samsung.com>
> ---
> v1 ---> Incorporated Johan's comments - Instead of fixing in hci_acldata_packet(),
> move sending mgmt_connected to l2cap_connect_req since this code is mainly to
> handle the scenario if remote device sends l2cap connection too fast
>
> net/bluetooth/hci_core.c | 8 --------
> net/bluetooth/l2cap_core.c | 11 +++++++++++
> 2 files changed, 11 insertions(+), 8 deletions(-)
Patch has been applied to bluetooth.git. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH] Bluetooth device 04ca:3008 should use ath3k
From: Gustavo Padovan @ 2013-01-10 5:17 UTC (permalink / raw)
To: Sergio Cambra; +Cc: linux-bluetooth, Sergio Cambra
In-Reply-To: <1357776415-6974-1-git-send-email-sergio@enpijama.es>
Hi Sergio,
* Sergio Cambra <sergio@enpijama.es> [2013-01-10 01:06:55 +0100]:
> From: Sergio Cambra <sergio@programatica.es>
>
> Output of /sys/kernel/debug/usb/devices
> T: Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 6 Spd=12 MxCh= 0
> D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=04ca ProdID=3008 Rev= 0.02
> C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
> I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
>
> Signed-off-by: Sergio Cambra <sergio@programatica.es>
> ---
> drivers/bluetooth/ath3k.c | 2 ++
> drivers/bluetooth/btusb.c | 1 +
> 2 files changed, 3 insertions(+)
Patch has been applied to bluetooth.git. Thanks.
Gustavo
^ permalink raw reply
* [PATCH v1] Bluetooth: Fix authentication if acl data comes before remote feature evt
From: Jaganath Kanakkassery @ 2013-01-10 4:58 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jaganath Kanakkassery
If remote device sends l2cap info request before read_remote_ext_feature
completes then mgmt_connected will be sent in hci_acldata_packet() and
remote name request wont be sent and eventually authentication wont happen
Hcidump log of the issue
< HCI Command: Create Connection (0x01|0x0005) plen 13
bdaddr BC:85:1F:74:7F:29 ptype 0xcc18 rswitch 0x01 clkoffset 0x4bf7 (valid)
Packet type: DM1 DM3 DM5 DH1 DH3 DH5
> HCI Event: Command Status (0x0f) plen 4
Create Connection (0x01|0x0005) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 12 bdaddr BC:85:1F:74:7F:29 type ACL encrypt 0x00
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
handle 12
> HCI Event: Command Status (0x0f) plen 4
Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
> HCI Event: Read Remote Supported Features (0x0b) plen 11
status 0x00 handle 12
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
> HCI Event: Max Slots Change (0x1b) plen 3
handle 12 slots 5
< HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3
handle 12 page 1
> HCI Event: Command Status (0x0f) plen 4
Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
> ACL data: handle 12 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
< ACL data: handle 12 flags 0x00 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x00b8
Enhanced Retransmission mode
Streaming mode
FCS Option
Fixed Channels
> HCI Event: Read Remote Extended Features (0x23) plen 13
status 0x00 handle 12 page 1 max 1
Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> ACL data: handle 12 flags 0x02 dlen 10
L2CAP(s): Info req: type 3
< ACL data: handle 12 flags 0x00 dlen 20
L2CAP(s): Info rsp: type 3 result 0
Fixed channel list 0x00000002
L2CAP Signalling Channel
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
This patch moves sending mgmt_connected from hci_acldata_packet() to
l2cap_connect_req() since this code is to handle the scenario remote
device sends l2cap connect req too fast
Signed-off-by: Jaganath Kanakkassery <jaganath.k@samsung.com>
---
v1 ---> Incorporated Johan's comments - Instead of fixing in hci_acldata_packet(),
move sending mgmt_connected to l2cap_connect_req since this code is mainly to
handle the scenario if remote device sends l2cap connection too fast
net/bluetooth/hci_core.c | 8 --------
net/bluetooth/l2cap_core.c | 11 +++++++++++
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 596660d..0f78e34 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2810,14 +2810,6 @@ static void hci_acldata_packet(struct hci_dev *hdev, struct sk_buff *skb)
if (conn) {
hci_conn_enter_active_mode(conn, BT_POWER_FORCE_ACTIVE_OFF);
- hci_dev_lock(hdev);
- if (test_bit(HCI_MGMT, &hdev->dev_flags) &&
- !test_and_set_bit(HCI_CONN_MGMT_CONNECTED, &conn->flags))
- mgmt_device_connected(hdev, &conn->dst, conn->type,
- conn->dst_type, 0, NULL, 0,
- conn->dev_class);
- hci_dev_unlock(hdev);
-
/* Send to upper protocol */
l2cap_recv_acldata(conn, skb, flags);
return;
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 82a3bdc..7c7e932 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -3722,6 +3722,17 @@ sendresp:
static int l2cap_connect_req(struct l2cap_conn *conn,
struct l2cap_cmd_hdr *cmd, u8 *data)
{
+ struct hci_dev *hdev = conn->hcon->hdev;
+ struct hci_conn *hcon = conn->hcon;
+
+ hci_dev_lock(hdev);
+ if (test_bit(HCI_MGMT, &hdev->dev_flags) &&
+ !test_and_set_bit(HCI_CONN_MGMT_CONNECTED, &hcon->flags))
+ mgmt_device_connected(hdev, &hcon->dst, hcon->type,
+ hcon->dst_type, 0, NULL, 0,
+ hcon->dev_class);
+ hci_dev_unlock(hdev);
+
l2cap_connect(conn, cmd, data, L2CAP_CONN_RSP, 0);
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH BlueZ 2/2] unit: Print D-Bus error message in verbose mode
From: Marcel Holtmann @ 2013-01-10 1:22 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <1357779808-25513-2-git-send-email-anderson.lizardo@openbossa.org>
Hi Anderson,
> If g_dbus_setup_private() fails (e.g. a session bus is not available,
> and there is no X11 for dbus-launch to work), the tests are silently
> skipped.
>
> With this commit, the D-Bus error message is also printed if verbose
> mode is enabled. The test is still skipped as before.
> ---
> unit/test-gdbus-client.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
patch has been applied.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH BlueZ 1/2] unit: Fix intermitent failure of SDP tests
From: Marcel Holtmann @ 2013-01-10 1:21 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <1357779808-25513-1-git-send-email-anderson.lizardo@openbossa.org>
Hi Anderson,
change the subject of the commit ;)
> While running tests, the D-Bus library was set to call _exit() when the
> client leaves the bus. This caused the second test to be interrupted
> without providing a PASS/FAIL result. This was confirmed by running
> test-sdp with DBUS_VERBOSE=1.
>
> This commit disables this behavior, which does not exist on BlueZ
> because g_dbus_set_disconnect_function() implicitly does this.
> ---
> unit/test-gdbus-client.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/unit/test-gdbus-client.c b/unit/test-gdbus-client.c
> index 7c849f0..cfbe4e0 100644
> --- a/unit/test-gdbus-client.c
> +++ b/unit/test-gdbus-client.c
> @@ -68,6 +68,10 @@ static struct context *create_context(void)
> return NULL;
> }
>
> + /* Make sure D-Bus library will not call _exit() and interrupt the next
> + * tests. */
Can you make this a one-line comment like this or similar:
/* Avoid D-Bus library calling _exit() before next test */
> + dbus_connection_set_exit_on_disconnect(context->dbus_conn, FALSE);
> +
> return context;
> }
>
Regards
Marcel
^ permalink raw reply
* RE: sd8688 firmware location
From: Bing Zhao @ 2013-01-10 1:20 UTC (permalink / raw)
To: Dan Williams, Lubomir Rintel
Cc: David Woodhouse, Ben Hutchings, libertas-dev@lists.infradead.org,
linux-bluetooth@vger.kernel.org, Gustavo Padovan, Marcel Holtmann,
Johan Hedberg, linux-kernel@vger.kernel.org
In-Reply-To: <1357771504.12030.59.camel@dcbw.foobar.com>
SGkgRGFuLA0KDQo+ID4gYnRtcnZsX3NkaW8gYW5kIGxpYmVydGFzX3NkaW8gYm90aCB1c2UgZmly
bXdhcmUgZmlsZXMgc2Q4Njg4LmJpbiBhbmQNCj4gPiBzZDg2ODhfaGVscGVyLmJpbi4gSW4gbGlu
dXgtZmlybXdhcmUsIHRoZXkncmUgcHJlc2VudCBpbiBsaWJlcnRhcy8gdHJlZSBhbmQNCj4gPiAo
c2luY2UgM2QzMmE1OGIpIGxpYmVydGFzX3NkaW8gcGVyZmVycyBsb2FkaW5nIGl0IGZyb20gdGhl
cmUsIHdoaWxlIGl0IGlzIGFibGUNCj4gPiB0byBmYWxsYmFjayB0byBsb2FkIGl0IGZyb20gbGlu
dXgtZmlybXdhcmUgcm9vdC4gYnRtcnZsX3NkaW8sIG9uIHRoZSBvdGhlciBoYW5kDQo+ID4gb25s
eSBsb29rcyBpbiB0aGUgcm9vdCBhbmQgZW5kcyB1cCBub3QgYmVpbmcgc3VjY2Vzc2Z1bC4NCj4g
Pg0KPiA+IE9idmlvdXNseSwgdGhlcmUgYXJlIHR3byBzb2x1dGlvbnMgdG8gdGhlIHByb2JsZW0g
LS0gZWl0aGVyIHRlYWNoIGJ0bXJ2bF9zZGlvDQo+ID4gdG8gbG9vayBpbnRvIGxpYmVydGFzLywg
b3IgbW92ZSB0aGUgZmlsZXMgaW4gbGludXgtZmlybXdhcmUgdHJlZS4gSSBkb24ndA0KPiA+IHJl
YWxseSBoYXZlIGEgc3Ryb25nIHByZWZlcmVuY2UsIHRob3VnaCBpdCBwcm9iYWJseSBtYWtlcyBs
ZXNzIHNlbnNlIHRvIGtlZXAgaW4NCj4gPiBpbiBsaWJlcnRhcy8sIHNpbmNlIHRoZSBibHVldG9v
dGggaGFyZHdhcmUgaXMgbm90IHJlYWxseSBtYXJrZXRlZCBhcyAiTGliZXJ0YXMuIg0KPiA+DQo+
ID4gSSdtIGZvbGxvd2luZyB1cCB3aXRoIHBhdGNoZXMgdG8gbGludXggYW5kIGxpbnV4LWZpcm13
YXJlIGFuZCBJJ2QgYmUgdmVyeQ0KPiA+IHRoYW5rZnVsIGlmIHlvdSBjb3VsZCBwaWNrIG9uZSAo
bm90IGJvdGggb2YgdGhlbSkuDQo+IA0KPiBTbyB0aGUgQlQgcGFydCBhbmQgdGhlIHdpZmkgcGFy
dCBoYXZlIGRpZmZlcmVudCBTRElPIElEczsgYXJlIHRoZXkNCj4gYWN0dWFsbHkgY29ubmVjdGVk
IHNlcGFyYXRlbHkgdG8gdGhlIFNESU8gYnVzPyAgT3IgaXMgdGhlIGNoaXAgb25seSBpbg0KPiBv
bmUgbW9kZSBhdCBvbmUgdGltZSBvciBzb21ldGhpbmcgbGlrZSB0aGF0PyAgSXMgdGhlcmUgYSBw
cm9ibGVtIHdpdGgNCj4gaGF2aW5nIGJvdGggbGliZXJ0YXMgYW5kIGJ0bXJ2bCBsb2FkZWQgYXQg
dGhlIHNhbWUgdGltZSBzaW5jZSB0aGV5J3JlDQo+IGVzc2VudGlhbGx5IHRoZSBzYW1lIGNoaXA/
DQoNClNEODY4OCBpcyBhIGNvbWJvIGNoaXAgd2l0aCBkaWZmZXJlbnQgZGV2aWNlIElEcyBmb3Ig
V0xBTiAoZnVuY3Rpb24gMSkgYW5kIEJUIChmdW5jdGlvbiAyKS4gV0xBTiArIEJUIHRvZ2V0aGVy
IGFyZSBjb25uZWN0ZWQgdG8gdGhlIGJ1cyB3aXRoIGEgc2luZ2xlIFNESU8gaW50ZXJmYWNlLiBC
b3RoIGxpYmVydGFzIGFuZCBidG1ydmwgZHJpdmVycyBjYW4gYmUgbG9hZGVkIGF0IHRoZSBzYW1l
IHRpbWUsIGFuZCBXTEFOICYgQlQgZnVuY3Rpb25zIHdvcmsgY29uY3VycmVudGx5LiBPZiBjb3Vy
c2UgdGhlIFNESU8gYnVzIGlzIHNoYXJlZCBiZXR3ZWVuIFdMQU4gYW5kIEJULg0KDQpUaGUgZmly
bXdhcmUgaW1hZ2UgY2FuIGJlIGRvd25sb2FkZWQgZnJvbSBob3N0IHRvIGRldmljZSBieSBlaXRo
ZXIgbGliZXJ0YXMgb3IgYnRtcnZsIGRyaXZlciB3aG9ldmVyIGJlY29tZXMgdGhlIHdpbm5lciBm
cm9tIGZpcm13YXJlIGRvd25sb2FkaW5nIHBlcnNwZWN0aXZlLg0KDQpSZWdhcmRzLA0KQmluZw0K
DQo+IA0KPiBJIGRvbid0IHJlYWxseSBtaW5kIG1vdmluZyBzdHVmZiB0byBtcnZsLyBvdXQgb2Yg
bGliZXJ0YXMvIGZvciB0aGVzZQ0KPiBkZXZpY2VzLCBidXQgSSBkbyB3YW50IHNvbWUgYmFja3dh
cmRzIGNvbXBhdCBjb2RlIGluIGxpYmVydGFzIGZvciB0aGF0Lg0KPiBVbmxlc3MsIG9mIGNvdXJz
ZSwgTWFyY2VsIHdhcyB0YWxraW5nIGFib3V0IHN5bWxpbmtzIGluIHRoZQ0KPiBsaW51eC1maXJt
d2FyZSBnaXQgdHJlZSwgd2hpY2ggd291bGQgYmUgZmluZSB3aXRoIG1lLiAgVGhlIGltcG9ydGFu
dA0KPiBwb2ludCBpcyB0aGF0IHNpbXBseSB1cGRhdGluZyB5b3VyIGxpbnV4LWZpcm13YXJlIHBh
Y2thZ2Ugb3IgaW5zdGFsbCBvcg0KPiB3aGF0ZXZlciAqc2hvdWxkIG5vdCogcmVzdWx0IGluIGEg
ZmFpbGVkIGZpcm13YXJlIGxvYWQuDQo+IA0KPiBEYW4NCg==
^ permalink raw reply
* [PATCH BlueZ 2/2] unit: Print D-Bus error message in verbose mode
From: Anderson Lizardo @ 2013-01-10 1:03 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
In-Reply-To: <1357779808-25513-1-git-send-email-anderson.lizardo@openbossa.org>
If g_dbus_setup_private() fails (e.g. a session bus is not available,
and there is no X11 for dbus-launch to work), the tests are silently
skipped.
With this commit, the D-Bus error message is also printed if verbose
mode is enabled. The test is still skipped as before.
---
unit/test-gdbus-client.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/unit/test-gdbus-client.c b/unit/test-gdbus-client.c
index cfbe4e0..5821414 100644
--- a/unit/test-gdbus-client.c
+++ b/unit/test-gdbus-client.c
@@ -53,6 +53,7 @@ static const GDBusPropertyTable properties[] = {
static struct context *create_context(void)
{
struct context *context = g_new0(struct context, 1);
+ DBusError err;
context->main_loop = g_main_loop_new(NULL, FALSE);
if (context->main_loop == NULL) {
@@ -60,9 +61,18 @@ static struct context *create_context(void)
return NULL;
}
+ dbus_error_init(&err);
+
context->dbus_conn = g_dbus_setup_private(DBUS_BUS_SESSION,
- SERVICE_NAME, NULL);
+ SERVICE_NAME, &err);
if (context->dbus_conn == NULL) {
+ if (dbus_error_is_set(&err)) {
+ if (g_test_verbose())
+ g_printerr("D-Bus setup failed: %s\n",
+ err.message);
+ dbus_error_free(&err);
+ }
+
g_main_loop_unref(context->main_loop);
g_free(context);
return NULL;
--
1.7.9.5
^ permalink raw reply related
* [PATCH BlueZ 1/2] unit: Fix intermitent failure of SDP tests
From: Anderson Lizardo @ 2013-01-10 1:03 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
While running tests, the D-Bus library was set to call _exit() when the
client leaves the bus. This caused the second test to be interrupted
without providing a PASS/FAIL result. This was confirmed by running
test-sdp with DBUS_VERBOSE=1.
This commit disables this behavior, which does not exist on BlueZ
because g_dbus_set_disconnect_function() implicitly does this.
---
unit/test-gdbus-client.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/unit/test-gdbus-client.c b/unit/test-gdbus-client.c
index 7c849f0..cfbe4e0 100644
--- a/unit/test-gdbus-client.c
+++ b/unit/test-gdbus-client.c
@@ -68,6 +68,10 @@ static struct context *create_context(void)
return NULL;
}
+ /* Make sure D-Bus library will not call _exit() and interrupt the next
+ * tests. */
+ dbus_connection_set_exit_on_disconnect(context->dbus_conn, FALSE);
+
return context;
}
--
1.7.9.5
^ permalink raw reply related
* RE: [PATCH] Bluetooth: fix the oops due to conn->hcon == NULL in shutdown case
From: Liu, Chuansheng @ 2013-01-10 0:26 UTC (permalink / raw)
To: Gustavo Padovan
Cc: marcel@holtmann.org, johan.hedberg@gmail.com,
linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20130109203444.GC30225@joana>
Hi Gustavo,
> -----Original Message-----
> From: Gustavo Padovan [mailto:gustavo@padovan.org]
> Sent: Thursday, January 10, 2013 4:35 AM
> To: Liu, Chuansheng
> Cc: marcel@holtmann.org; johan.hedberg@gmail.com;
> linux-bluetooth@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] Bluetooth: fix the oops due to conn->hcon =3D=3D NUL=
L in
> shutdown case
>=20
> Hi Liu,
>=20
> * Liu, Chuansheng <chuansheng.liu@intel.com> [2013-01-04 00:55:26 +0000]:
>=20
> >
> >
> > > -----Original Message-----
> > > From: Gustavo Padovan [mailto:gustavo@padovan.org]
> > > Sent: Friday, January 04, 2013 6:03 AM
> > > To: Liu, Chuansheng
> > > Cc: marcel@holtmann.org; johan.hedberg@gmail.com;
> > > linux-bluetooth@vger.kernel.org; linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH] Bluetooth: fix the oops due to conn->hcon =3D=3D=
NULL in
> > > shutdown case
> > >
> > > Hi Chuansheng,
> > >
> > > * Chuansheng Liu <chuansheng.liu@intel.com> [2012-12-25 18:04:17
> +0800]:
> > >
> > > >
> > > > Meet one panic issue as below stack:
> >
> >
> > > > Disassemble the code:
> > > > base address of __sco_sock_close is 0xc184f410
> > > > 0xc184f4f8 <+232>: lock decl 0x8(%ebx) < =3D=3D crash here, ebx i=
s 0x0,
> > > >
> > > > the related source code is:
> > > > (gdb) l *0xc184f4f8
> > > > 0xc184f4f8 is in __sco_sock_close (arch/x86/include/asm/atomic.h:12=
3)
> > > > 119 static inline int atomic_dec_and_test(atomic_t *v)
> > > > 123 asm volatile(LOCK_PREFIX "decl %0; sete %1"
> > > >
> > > > The whole call stack is:
> > > > sys_shutdown()
> > > > sco_sock_shutdown()
> > > > __sco_sock_close()
> > > > hci_conn_put()
> > > > atomic_dec_and_test()
> > > >
> > > > Due to the conn->hcon is NULL, and the member hcon->refcnt is at of=
fset
> 0x8,
> > > > so "BUG: unable to handle kernel NULL pointer dereference at 000000=
08"
> > > > appears.
> > Could you add the above crash info to indicate where crashed? Thanks.
> >
> > > >
> > > > Here fix it that adding the condition if conn->hcon is NULL, just l=
ike
> > > > in sco_chan_del().
> > > >
> > > > Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
> > > > ---
> > > > net/bluetooth/sco.c | 6 ++++--
> > > > 1 files changed, 4 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
> > > > index 531a93d..190f70c 100644
> > > > --- a/net/bluetooth/sco.c
> > > > +++ b/net/bluetooth/sco.c
> > > > @@ -355,8 +355,10 @@ static void __sco_sock_close(struct sock *sk)
> > > > if (sco_pi(sk)->conn) {
> > > > sk->sk_state =3D BT_DISCONN;
> > > > sco_sock_set_timer(sk, SCO_DISCONN_TIMEOUT);
> > > > - hci_conn_put(sco_pi(sk)->conn->hcon);
> > > > - sco_pi(sk)->conn->hcon =3D NULL;
> > > > + if (sco_pi(sk)->conn->hcon) {
> > > > + hci_conn_put(sco_pi(sk)->conn->hcon);
> > > > + sco_pi(sk)->conn->hcon =3D NULL;
> > > > + }
> > > > } else
> > > > sco_chan_del(sk, ECONNRESET);
> > > > break;
> > >
> > > Please check if the following patch fixes the issue for you:
> > >
> > > commit ae5668c1fc155d3034d0eedcdb52798390975a39 (HEAD, master)
> > > Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> > > Date: Thu Jan 3 19:59:28 2013 -0200
> > >
> > > Bluetooth: Check if the hci connection exists in SCO shutdown
> > >
> > > Checking only for sco_conn seems to not be enough and lead to NUL=
L
> > > dereferences in the code, check for hcon instead.
> > >
> > > <1>[11340.226404] BUG: unable to handle kernel NULL pointer
> > > dereference at
> > > 0000000
> > > 8
> > > <4>[11340.226619] EIP is at __sco_sock_close+0xe8/0x1a0
> > > <4>[11340.226629] EAX: f063a740 EBX: 00000000 ECX: f58f4544 EDX:
> > > 00000000
> > > <4>[11340.226640] ESI: dec83e00 EDI: 5f9a081f EBP: e0fdff38 ESP:
> > > e0fdff1c
> > > <0>[11340.226674] Stack:
> > > <4>[11340.226682] c184db87 c1251028 dec83e00 e0fdff38
> c1754aef
> > > dec83e00
> > > 00000000
> > > e0fdff5c
> > > <4>[11340.226718] c184f587 e0fdff64 e0fdff68 5f9a081f e0fdff5c
> > > c1751852
> > > d7813800
> > > 62262f10
> > > <4>[11340.226752] e0fdff70 c1753c00 00000000 00000001
> 0000000d
> > > e0fdffac
> > > c175425c
> > > 00000041
> > > <0>[11340.226793] Call Trace:
> > > <4>[11340.226813] [<c184db87>] ?
> sco_sock_clear_timer+0x27/0x60
> > > <4>[11340.226831] [<c1251028>] ? local_bh_enable+0x68/0xd0
> > > <4>[11340.226846] [<c1754aef>] ? lock_sock_nested+0x4f/0x60
> > > <4>[11340.226862] [<c184f587>] sco_sock_shutdown+0x67/0xb0
> > > <4>[11340.226879] [<c1751852>] ? sockfd_lookup_light+0x22/0x80
> > > <4>[11340.226897] [<c1753c00>] sys_shutdown+0x30/0x60
> > > <4>[11340.226912] [<c175425c>] sys_socketcall+0x1dc/0x2a0
> > > <4>[11340.226929] [<c149ba78>] ?
> trace_hardirqs_on_thunk+0xc/0x10
> > > <4>[11340.226944] [<c18860f1>] syscall_call+0x7/0xb
> > > <4>[11340.226960] [<c1880000>] ? restore_cur+0x5e/0xd7
> > > <0>[11340.226969] Code: <f0> ff 4b 08 0f 94 c0 84 c0 74 20 80 7b =
19
> 01 74
> > > 2f b8 0a 00 00
> > >
> > > Reported-by: Chuansheng Liu <chuansheng.liu@intel.com>
> > > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> > >
> > > diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
> > > index 531a93d..57f250c 100644
> > > --- a/net/bluetooth/sco.c
> > > +++ b/net/bluetooth/sco.c
> > > @@ -352,7 +352,7 @@ static void __sco_sock_close(struct sock *sk)
> > >
> > > case BT_CONNECTED:
> > > case BT_CONFIG:
> > > - if (sco_pi(sk)->conn) {
> > > + if (sco_pi(sk)->conn->hcon) {
> > Your fix is incomplete, at least it should be:
> > if ( (sco_pi(sk)->conn) && (sco_pi(sk)->conn->hcon)) {
> > Otherwise, it will bring another crash case. So could you add signed-of=
f-by me
> also?
>=20
> Can you point any code flow that can crash with my patch? Otherwise I'm j=
ust
> pushing this patch. I don't think we need to check for sco_pi(sk)->conn h=
ere.
My theory is the old code if(sco_pi(sk)->conn) is already there, unless you=
think it is useless and impossible.
Just a code review for me, if you think your patch is still OK, please push=
ing it, thanks.
And I will try it to reproduce if possible:(
>=20
> Gustavo
^ permalink raw reply
* [PATCH] Bluetooth device 04ca:3008 should use ath3k
From: Sergio Cambra @ 2013-01-10 0:06 UTC (permalink / raw)
To: Gustavo Padovan; +Cc: linux-bluetooth, Sergio Cambra
In-Reply-To: <20130109195346.GB30225@joana>
From: Sergio Cambra <sergio@programatica.es>
Output of /sys/kernel/debug/usb/devices
T: Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 6 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=04ca ProdID=3008 Rev= 0.02
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Signed-off-by: Sergio Cambra <sergio@programatica.es>
---
drivers/bluetooth/ath3k.c | 2 ++
drivers/bluetooth/btusb.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index be17894..33c9a44 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -78,6 +78,7 @@ static struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x13d3, 0x3375) },
{ USB_DEVICE(0x04CA, 0x3005) },
{ USB_DEVICE(0x04CA, 0x3006) },
+ { USB_DEVICE(0x04CA, 0x3008) },
{ USB_DEVICE(0x13d3, 0x3362) },
{ USB_DEVICE(0x0CF3, 0xE004) },
{ USB_DEVICE(0x0930, 0x0219) },
@@ -109,6 +110,7 @@ static struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3006), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 3f6a993..7e351e3 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -136,6 +136,7 @@ static struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3006), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
--
1.8.0.2
^ permalink raw reply related
* Re: sd8688 firmware location
From: Dan Williams @ 2013-01-09 22:45 UTC (permalink / raw)
To: Lubomir Rintel
Cc: David Woodhouse, Ben Hutchings, libertas-dev, linux-bluetooth,
Gustavo Padovan, Marcel Holtmann, Johan Hedberg, linux-kernel
In-Reply-To: <1357689361-7969-1-git-send-email-lkundrak@v3.sk>
On Wed, 2013-01-09 at 00:56 +0100, Lubomir Rintel wrote:
> Hi!
>
> btmrvl_sdio and libertas_sdio both use firmware files sd8688.bin and
> sd8688_helper.bin. In linux-firmware, they're present in libertas/ tree and
> (since 3d32a58b) libertas_sdio perfers loading it from there, while it is able
> to fallback to load it from linux-firmware root. btmrvl_sdio, on the other hand
> only looks in the root and ends up not being successful.
>
> Obviously, there are two solutions to the problem -- either teach btmrvl_sdio
> to look into libertas/, or move the files in linux-firmware tree. I don't
> really have a strong preference, though it probably makes less sense to keep in
> in libertas/, since the bluetooth hardware is not really marketed as "Libertas."
>
> I'm following up with patches to linux and linux-firmware and I'd be very
> thankful if you could pick one (not both of them).
So the BT part and the wifi part have different SDIO IDs; are they
actually connected separately to the SDIO bus? Or is the chip only in
one mode at one time or something like that? Is there a problem with
having both libertas and btmrvl loaded at the same time since they're
essentially the same chip?
I don't really mind moving stuff to mrvl/ out of libertas/ for these
devices, but I do want some backwards compat code in libertas for that.
Unless, of course, Marcel was talking about symlinks in the
linux-firmware git tree, which would be fine with me. The important
point is that simply updating your linux-firmware package or install or
whatever *should not* result in a failed firmware load.
Dan
^ permalink raw reply
* Re: [RFC] Bluetooth: Allow getting SCO options for not connected sockets
From: Gustavo Padovan @ 2013-01-09 21:41 UTC (permalink / raw)
To: Vinicius Costa Gomes; +Cc: linux-bluetooth
In-Reply-To: <1357138055-28765-1-git-send-email-vinicius.gomes@openbossa.org>
Hi Vinicius,
* Vinicius Costa Gomes <vinicius.gomes@openbossa.org> [2013-01-02 11:47:35 -0300]:
> Now, that we have proper support for deferred setup for SCO sockets it
> is very convenient that we are able to get the socket options for
> sockets that are not in the 'connected' state.
>
> And makes the behaviour more consistent with what L2CAP does, for
> example.
>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
> ---
>
> Sending this as a RFC, because even though I couldn't think of any cases
> that this new behaviour would surprise userspace applications, there
> may be still be some.
>
> net/bluetooth/sco.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
> index 531a93d..271320c 100644
> --- a/net/bluetooth/sco.c
> +++ b/net/bluetooth/sco.c
> @@ -730,11 +730,6 @@ static int sco_sock_getsockopt_old(struct socket *sock, int optname, char __user
>
> switch (optname) {
> case SCO_OPTIONS:
> - if (sk->sk_state != BT_CONNECTED) {
> - err = -ENOTCONN;
> - break;
> - }
> -
> opts.mtu = sco_pi(sk)->conn->mtu;
>
> BT_DBG("mtu %d", opts.mtu);
I'm ok with this patch, if someone else has something against it, please tell
me.
Gustavo
^ permalink raw reply
* Re: [PATCH v2 2/2] Bluetooth: Fix stop discovery while in STARTING state
From: Gustavo Padovan @ 2013-01-09 21:37 UTC (permalink / raw)
To: Jaganath Kanakkassery; +Cc: linux-bluetooth
In-Reply-To: <D76CDD18C783483EAF643D1B392FFAEA@sisodomain.com>
Hi Jaganath,
* Jaganath Kanakkassery <jaganath.k@samsung.com> [2013-01-04 13:16:11 +0530]:
> Hi Gustavo,
>
> --------------------------------------------------
> From: "Gustavo Padovan" <gustavo@padovan.org>
> Sent: Friday, January 04, 2013 1:08 AM
> To: "Jaganath Kanakkassery" <jaganath.k@samsung.com>
> Cc: <linux-bluetooth@vger.kernel.org>
> Subject: Re: [PATCH v2 2/2] Bluetooth: Fix stop discovery while in
> STARTING state
>
> >Hi Jaganath,
> >
> >* Jaganath Kanakkassery <jaganath.k@samsung.com> [2012-12-21
> >18:20:25 +0530]:
> >
> >>If stop_discovery() is called when discovery state is STARTING, it
> >>will be failed currently. This patch fixes this.
> >>
> >>Signed-off-by: Jaganath Kanakkassery <jaganath.k@samsung.com>
> >>---
> >> include/net/bluetooth/hci_core.h | 2 ++
> >> net/bluetooth/hci_event.c | 14 ++++++++++++--
> >> net/bluetooth/mgmt.c | 31 ++++++++++++++++++++++++++++++-
> >> 3 files changed, 44 insertions(+), 3 deletions(-)
> >>
> >>diff --git a/include/net/bluetooth/hci_core.h
> >>b/include/net/bluetooth/hci_core.h
> >>index 119fcb6..c2886b7 100644
> >>--- a/include/net/bluetooth/hci_core.h
> >>+++ b/include/net/bluetooth/hci_core.h
> >>@@ -64,6 +64,7 @@ struct discovery_state {
> >> DISCOVERY_RESOLVING,
> >> DISCOVERY_STOPPING,
> >> } state;
> >>+ u8 discovering;
> >> struct list_head all; /* All devices found during inquiry */
> >> struct list_head unknown; /* Name state not known */
> >> struct list_head resolve; /* Name needs to be resolved */
> >>@@ -1066,6 +1067,7 @@ int mgmt_device_found(struct hci_dev
> >>*hdev, bdaddr_t *bdaddr, u8 link_type,
> >> int mgmt_remote_name(struct hci_dev *hdev, bdaddr_t *bdaddr, u8
> >>link_type,
> >> u8 addr_type, s8 rssi, u8 *name, u8 name_len);
> >> int mgmt_start_discovery_failed(struct hci_dev *hdev, u8 status);
> >>+int mgmt_start_discovery_complete(struct hci_dev *hdev, u8 status);
> >> int mgmt_stop_discovery_failed(struct hci_dev *hdev, u8 status);
> >> int mgmt_discovering(struct hci_dev *hdev, u8 discovering);
> >> int mgmt_interleaved_discovery(struct hci_dev *hdev);
> >>diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> >>index e248e7c..b486458 100644
> >>--- a/net/bluetooth/hci_event.c
> >>+++ b/net/bluetooth/hci_event.c
> >>@@ -1092,7 +1092,12 @@ static void
> >>hci_cc_le_set_scan_enable(struct hci_dev *hdev,
> >> set_bit(HCI_LE_SCAN, &hdev->dev_flags);
> >>
> >> hci_dev_lock(hdev);
> >>- hci_discovery_set_state(hdev, DISCOVERY_FINDING);
> >>+ if (hdev->discovery.state == DISCOVERY_STOPPING) {
> >>+ hci_cancel_le_scan(hdev);
> >>+ mgmt_start_discovery_complete(hdev, 0);
> >
> >Reply to mgmt with an error here might be better.
>
> I think the best error which can be given here is
> MGMT_STATUS_CANCELLED. But this error is not accessible in hci_event.c
>
> >>+ } else {
> >>+ hci_discovery_set_state(hdev, DISCOVERY_FINDING);
> >>+ }
> >> hci_dev_unlock(hdev);
> >> break;
> >>
> >>@@ -1189,7 +1194,12 @@ static void hci_cs_inquiry(struct hci_dev
> >>*hdev, __u8 status)
> >> set_bit(HCI_INQUIRY, &hdev->flags);
> >>
> >> hci_dev_lock(hdev);
> >>- hci_discovery_set_state(hdev, DISCOVERY_FINDING);
> >>+ if (hdev->discovery.state == DISCOVERY_STOPPING) {
> >>+ hci_cancel_inquiry(hdev);
> >>+ mgmt_start_discovery_complete(hdev, 0);
> >>+ } else {
> >>+ hci_discovery_set_state(hdev, DISCOVERY_FINDING);
> >>+ }
> >> hci_dev_unlock(hdev);
> >> }
> >>
> >>diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> >>index d6c0d78..ba4171f 100644
> >>--- a/net/bluetooth/mgmt.c
> >>+++ b/net/bluetooth/mgmt.c
> >>@@ -2385,7 +2385,8 @@ static int stop_discovery(struct sock *sk,
> >>struct hci_dev *hdev, void *data,
> >>
> >> hci_dev_lock(hdev);
> >>
> >>- if (!hci_discovery_active(hdev)) {
> >>+ if (hdev->discovery.state != DISCOVERY_STARTING &&
> >>+ !hci_discovery_active(hdev)) {
> >> err = cmd_complete(sk, hdev->id, MGMT_OP_STOP_DISCOVERY,
> >> MGMT_STATUS_REJECTED, &mgmt_cp->type,
> >> sizeof(mgmt_cp->type));
> >>@@ -2433,6 +2434,10 @@ static int stop_discovery(struct sock
> >>*sk, struct hci_dev *hdev, void *data,
> >>
> >> break;
> >>
> >>+ case DISCOVERY_STARTING:
> >>+ err = 0;
> >>+ break;
> >>+
> >> default:
> >> BT_DBG("unknown discovery state %u", hdev->discovery.state);
> >> err = -EFAULT;
> >>@@ -3624,6 +3629,25 @@ int mgmt_start_discovery_failed(struct
> >>hci_dev *hdev, u8 status)
> >> return err;
> >> }
> >>
> >>+int mgmt_start_discovery_complete(struct hci_dev *hdev, u8 status)
> >>+{
> >>+ struct pending_cmd *cmd;
> >>+ u8 type;
> >>+ int err;
> >>+
> >>+ cmd = mgmt_pending_find(MGMT_OP_START_DISCOVERY, hdev);
> >>+ if (!cmd)
> >>+ return -ENOENT;
> >>+
> >>+ type = hdev->discovery.type;
> >>+
> >>+ err = cmd_complete(cmd->sk, hdev->id, cmd->opcode, mgmt_status(status),
> >>+ &type, sizeof(type));
> >>+ mgmt_pending_remove(cmd);
> >>+
> >>+ return err;
> >>+}
> >
> >This is exactly the same thing as mgmt_start_discovery_failed(),
> >just rename it
> >to _complete() as you did with mgmt_stop_discovery_failed(). Do it as a
> >separate patch.
>
> mgmt_start_discovery_failed() sets discovery state to STOPPED which
> also sends
> stop_discovery_complete internally. I think both are inappropriate
> at the point
> where mgmt_start_discovery_complete() is called.
>
> How abt renaming the new function mgmt_start_discovery_complete() to
> mgmt_start_discovery_cancelled and send MGMT_STATUS_CANCELLED in that?
Ok, go with this approach.
Gustavo
^ permalink raw reply
* Re: [PATCH v1] Bluetooth: Fix authentication if acl data comes before remote feature evt
From: Gustavo Padovan @ 2013-01-09 21:10 UTC (permalink / raw)
To: Jaganath Kanakkassery; +Cc: linux-bluetooth
In-Reply-To: <1357543751-12204-1-git-send-email-jaganath.k@samsung.com>
Hi Jaganath,
* Jaganath Kanakkassery <jaganath.k@samsung.com> [2013-01-07 12:59:11 +0530]:
> If remote device sends l2cap info request before read_remote_ext_feature
> completes then mgmt_connected will be sent in hci_acldata_packet() and
> remote name request wont be sent and eventually authentication wont happen
>
> Hcidump log of the issue
>
> < HCI Command: Create Connection (0x01|0x0005) plen 13
> bdaddr BC:85:1F:74:7F:29 ptype 0xcc18 rswitch 0x01 clkoffset 0x4bf7 (valid)
> Packet type: DM1 DM3 DM5 DH1 DH3 DH5
> > HCI Event: Command Status (0x0f) plen 4
> Create Connection (0x01|0x0005) status 0x00 ncmd 1
> > HCI Event: Connect Complete (0x03) plen 11
> status 0x00 handle 12 bdaddr BC:85:1F:74:7F:29 type ACL encrypt 0x00
> < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
> handle 12
> > HCI Event: Command Status (0x0f) plen 4
> Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
> > HCI Event: Read Remote Supported Features (0x0b) plen 11
> status 0x00 handle 12
> Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
> > HCI Event: Max Slots Change (0x1b) plen 3
> handle 12 slots 5
> < HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3
> handle 12 page 1
> > HCI Event: Command Status (0x0f) plen 4
> Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
> > ACL data: handle 12 flags 0x02 dlen 10
> L2CAP(s): Info req: type 2
> < ACL data: handle 12 flags 0x00 dlen 16
> L2CAP(s): Info rsp: type 2 result 0
> Extended feature mask 0x00b8
> Enhanced Retransmission mode
> Streaming mode
> FCS Option
> Fixed Channels
> > HCI Event: Read Remote Extended Features (0x23) plen 13
> status 0x00 handle 12 page 1 max 1
> Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> > ACL data: handle 12 flags 0x02 dlen 10
> L2CAP(s): Info req: type 3
> < ACL data: handle 12 flags 0x00 dlen 20
> L2CAP(s): Info rsp: type 3 result 0
> Fixed channel list 0x00000002
> L2CAP Signalling Channel
> > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 12 packets 2
>
> This patch moves sending mgmt_connected from hci_acldata_packet() to
> l2cap_connect_req() since this code is to handle the scenario remote
> device sends l2cap connect req too fast
> ---
> v1 ---> Incorporated Johan's comments - Instead of fixing in hci_acldata_packet(),
> move sending mgmt_connected to l2cap_connect_req since this code is mainly to
> handle the scenario if remote device sends l2cap connection too fast
>
> net/bluetooth/hci_core.c | 8 --------
> net/bluetooth/l2cap_core.c | 11 +++++++++++
> 2 files changed, 11 insertions(+), 8 deletions(-)
Could you please add your Signed-off-by line to the patch?
Gustavo
^ permalink raw reply
* Re: [PATCH] Bluetooth: fix the oops due to conn->hcon == NULL in shutdown case
From: Gustavo Padovan @ 2013-01-09 20:34 UTC (permalink / raw)
To: Liu, Chuansheng
Cc: marcel@holtmann.org, johan.hedberg@gmail.com,
linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <27240C0AC20F114CBF8149A2696CBE4A1FB42B@SHSMSX101.ccr.corp.intel.com>
Hi Liu,
* Liu, Chuansheng <chuansheng.liu@intel.com> [2013-01-04 00:55:26 +0000]:
>
>
> > -----Original Message-----
> > From: Gustavo Padovan [mailto:gustavo@padovan.org]
> > Sent: Friday, January 04, 2013 6:03 AM
> > To: Liu, Chuansheng
> > Cc: marcel@holtmann.org; johan.hedberg@gmail.com;
> > linux-bluetooth@vger.kernel.org; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH] Bluetooth: fix the oops due to conn->hcon == NULL in
> > shutdown case
> >
> > Hi Chuansheng,
> >
> > * Chuansheng Liu <chuansheng.liu@intel.com> [2012-12-25 18:04:17 +0800]:
> >
> > >
> > > Meet one panic issue as below stack:
>
>
> > > Disassemble the code:
> > > base address of __sco_sock_close is 0xc184f410
> > > 0xc184f4f8 <+232>: lock decl 0x8(%ebx) < == crash here, ebx is 0x0,
> > >
> > > the related source code is:
> > > (gdb) l *0xc184f4f8
> > > 0xc184f4f8 is in __sco_sock_close (arch/x86/include/asm/atomic.h:123)
> > > 119 static inline int atomic_dec_and_test(atomic_t *v)
> > > 123 asm volatile(LOCK_PREFIX "decl %0; sete %1"
> > >
> > > The whole call stack is:
> > > sys_shutdown()
> > > sco_sock_shutdown()
> > > __sco_sock_close()
> > > hci_conn_put()
> > > atomic_dec_and_test()
> > >
> > > Due to the conn->hcon is NULL, and the member hcon->refcnt is at offset 0x8,
> > > so "BUG: unable to handle kernel NULL pointer dereference at 00000008"
> > > appears.
> Could you add the above crash info to indicate where crashed? Thanks.
>
> > >
> > > Here fix it that adding the condition if conn->hcon is NULL, just like
> > > in sco_chan_del().
> > >
> > > Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
> > > ---
> > > net/bluetooth/sco.c | 6 ++++--
> > > 1 files changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
> > > index 531a93d..190f70c 100644
> > > --- a/net/bluetooth/sco.c
> > > +++ b/net/bluetooth/sco.c
> > > @@ -355,8 +355,10 @@ static void __sco_sock_close(struct sock *sk)
> > > if (sco_pi(sk)->conn) {
> > > sk->sk_state = BT_DISCONN;
> > > sco_sock_set_timer(sk, SCO_DISCONN_TIMEOUT);
> > > - hci_conn_put(sco_pi(sk)->conn->hcon);
> > > - sco_pi(sk)->conn->hcon = NULL;
> > > + if (sco_pi(sk)->conn->hcon) {
> > > + hci_conn_put(sco_pi(sk)->conn->hcon);
> > > + sco_pi(sk)->conn->hcon = NULL;
> > > + }
> > > } else
> > > sco_chan_del(sk, ECONNRESET);
> > > break;
> >
> > Please check if the following patch fixes the issue for you:
> >
> > commit ae5668c1fc155d3034d0eedcdb52798390975a39 (HEAD, master)
> > Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> > Date: Thu Jan 3 19:59:28 2013 -0200
> >
> > Bluetooth: Check if the hci connection exists in SCO shutdown
> >
> > Checking only for sco_conn seems to not be enough and lead to NULL
> > dereferences in the code, check for hcon instead.
> >
> > <1>[11340.226404] BUG: unable to handle kernel NULL pointer
> > dereference at
> > 0000000
> > 8
> > <4>[11340.226619] EIP is at __sco_sock_close+0xe8/0x1a0
> > <4>[11340.226629] EAX: f063a740 EBX: 00000000 ECX: f58f4544 EDX:
> > 00000000
> > <4>[11340.226640] ESI: dec83e00 EDI: 5f9a081f EBP: e0fdff38 ESP:
> > e0fdff1c
> > <0>[11340.226674] Stack:
> > <4>[11340.226682] c184db87 c1251028 dec83e00 e0fdff38 c1754aef
> > dec83e00
> > 00000000
> > e0fdff5c
> > <4>[11340.226718] c184f587 e0fdff64 e0fdff68 5f9a081f e0fdff5c
> > c1751852
> > d7813800
> > 62262f10
> > <4>[11340.226752] e0fdff70 c1753c00 00000000 00000001 0000000d
> > e0fdffac
> > c175425c
> > 00000041
> > <0>[11340.226793] Call Trace:
> > <4>[11340.226813] [<c184db87>] ? sco_sock_clear_timer+0x27/0x60
> > <4>[11340.226831] [<c1251028>] ? local_bh_enable+0x68/0xd0
> > <4>[11340.226846] [<c1754aef>] ? lock_sock_nested+0x4f/0x60
> > <4>[11340.226862] [<c184f587>] sco_sock_shutdown+0x67/0xb0
> > <4>[11340.226879] [<c1751852>] ? sockfd_lookup_light+0x22/0x80
> > <4>[11340.226897] [<c1753c00>] sys_shutdown+0x30/0x60
> > <4>[11340.226912] [<c175425c>] sys_socketcall+0x1dc/0x2a0
> > <4>[11340.226929] [<c149ba78>] ? trace_hardirqs_on_thunk+0xc/0x10
> > <4>[11340.226944] [<c18860f1>] syscall_call+0x7/0xb
> > <4>[11340.226960] [<c1880000>] ? restore_cur+0x5e/0xd7
> > <0>[11340.226969] Code: <f0> ff 4b 08 0f 94 c0 84 c0 74 20 80 7b 19 01 74
> > 2f b8 0a 00 00
> >
> > Reported-by: Chuansheng Liu <chuansheng.liu@intel.com>
> > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> >
> > diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
> > index 531a93d..57f250c 100644
> > --- a/net/bluetooth/sco.c
> > +++ b/net/bluetooth/sco.c
> > @@ -352,7 +352,7 @@ static void __sco_sock_close(struct sock *sk)
> >
> > case BT_CONNECTED:
> > case BT_CONFIG:
> > - if (sco_pi(sk)->conn) {
> > + if (sco_pi(sk)->conn->hcon) {
> Your fix is incomplete, at least it should be:
> if ( (sco_pi(sk)->conn) && (sco_pi(sk)->conn->hcon)) {
> Otherwise, it will bring another crash case. So could you add signed-off-by me also?
Can you point any code flow that can crash with my patch? Otherwise I'm just
pushing this patch. I don't think we need to check for sco_pi(sk)->conn here.
Gustavo
^ permalink raw reply
* Re: [PATCH v2 BlueZ 3/3] unit: Implement tests for sdp_extract_attr()
From: Anderson Lizardo @ 2013-01-09 20:13 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1357761036.1806.48.camel@aeonflux>
Hi Marcel,
On Wed, Jan 9, 2013 at 3:50 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> just remove both TODOs from the patch. I assume you will send updates on
> this.
Yes, I will prepare a series with tests for other valid input.
Using this macro for testing sequences is not possible given it is
implemented as a linked list. SEQ*/ALT* stuff need to be tested
separately.
Testing invalid input (and checking for error) is also important,
specially if it triggers some memory leak/corruption. But they will
use a different test function because it should always return a NULL
pointer instead.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [PATCH 7/8 v2] Bluetooth: Fix checking for exact values of boolean mgmt parameters
From: Marcel Holtmann @ 2013-01-09 20:13 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1357740319-5737-1-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> All mgmt_set_* commands that take a boolean value encoded in the form of
> a byte should only accept the values 0x00 and 0x01. This patch adds the
> necessary checks for this and returns "invalid params" responses if
> anything else is provided as the value.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> v2: Fix s/SET_SSP/SET_LE/ copy-paste issue
>
> net/bluetooth/mgmt.c | 36 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 6/8] Bluetooth: Move non-critical sections outside of the dev lock
From: Marcel Holtmann @ 2013-01-09 20:12 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1357738180-4128-7-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> This patch fixes sections of code that do not need hci_lock_dev to be
> outside of the lock. Such sections include code that do not touch the
> hdev at all as well as sections which just read a single byte from the
> supported_features value (i.e. all lmp_*_capable() macros).
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/mgmt.c | 46 ++++++++++++++++++----------------------------
> 1 file changed, 18 insertions(+), 28 deletions(-)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 5/8] Bluetooth: Fix returning proper command status for start_discovery
From: Marcel Holtmann @ 2013-01-09 20:10 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1357738180-4128-6-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> Management commands should whenever possible fail with proper command
> status or command complete events. This patch fixes the
> mgmt_start_discovery command to do this for the failure cases where an
> incorrect parameter value was passed to it ("not supported" if the
> parameter value was valid but the controller doesn't support it and
> "invalid params" if it isn't valid at all).
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/mgmt.c | 35 +++++++++++++++++++++++++----------
> 1 file changed, 25 insertions(+), 10 deletions(-)
>
> diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> index 6e6de9e..4f60540 100644
> --- a/net/bluetooth/mgmt.c
> +++ b/net/bluetooth/mgmt.c
> @@ -2377,31 +2377,46 @@ static int start_discovery(struct sock *sk, struct hci_dev *hdev,
>
> switch (hdev->discovery.type) {
> case DISCOV_TYPE_BREDR:
> - if (lmp_bredr_capable(hdev))
> + if (lmp_bredr_capable(hdev)) {
> err = hci_do_inquiry(hdev, INQUIRY_LEN_BREDR);
> - else
> - err = -ENOTSUPP;
> + } else {
> + err = cmd_status(sk, hdev->id, MGMT_OP_START_DISCOVERY,
> + MGMT_STATUS_NOT_SUPPORTED);
> + mgmt_pending_remove(cmd);
> + goto failed;
> + }
I would have done this the other way around.
if (!lmp_bredr_capable(...)) {
...
got failed;
}
err = hci_do_inquiry(hdev, INQUIRY_LEN_BREDR);
break;
> break;
>
> case DISCOV_TYPE_LE:
> - if (lmp_host_le_capable(hdev))
> + if (lmp_host_le_capable(hdev)) {
> err = hci_le_scan(hdev, LE_SCAN_TYPE, LE_SCAN_INT,
> LE_SCAN_WIN, LE_SCAN_TIMEOUT_LE_ONLY);
> - else
> - err = -ENOTSUPP;
> + } else {
> + err = cmd_status(sk, hdev->id, MGMT_OP_START_DISCOVERY,
> + MGMT_STATUS_NOT_SUPPORTED);
> + mgmt_pending_remove(cmd);
> + goto failed;
> + }
And same here.
> break;
>
> case DISCOV_TYPE_INTERLEAVED:
> - if (lmp_host_le_capable(hdev) && lmp_bredr_capable(hdev))
> + if (lmp_host_le_capable(hdev) && lmp_bredr_capable(hdev)) {
> err = hci_le_scan(hdev, LE_SCAN_TYPE, LE_SCAN_INT,
> LE_SCAN_WIN,
> LE_SCAN_TIMEOUT_BREDR_LE);
> - else
> - err = -ENOTSUPP;
> + } else {
> + err = cmd_status(sk, hdev->id, MGMT_OP_START_DISCOVERY,
> + MGMT_STATUS_NOT_SUPPORTED);
> + mgmt_pending_remove(cmd);
> + goto failed;
> + }
> break;
Also here.
>
> default:
> - err = -EINVAL;
> + err = cmd_status(sk, hdev->id, MGMT_OP_START_DISCOVERY,
> + MGMT_STATUS_INVALID_PARAMS);
> + mgmt_pending_remove(cmd);
> + goto failed;
> }
>
> if (err < 0)
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 4/8] Bluetooth: Fix accepting set_dev_class for non-BR/EDR controllers
From: Marcel Holtmann @ 2013-01-09 20:08 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1357738180-4128-5-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> The concept of Class of Device only exists for BR/EDR controllers. The
> mgmt_set_dev_class command should therefore return a proper "not
> supported" error if it is attempted for a controller that doesn't
> support BR/EDR (e.g. a single mode LE-only one).
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/mgmt.c | 6 ++++++
> 1 file changed, 6 insertions(+)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 3/8] Bluetooth: Fix checking for valid device class values
From: Marcel Holtmann @ 2013-01-09 20:07 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1357738180-4128-4-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> The two lowest bits of the minor device class value are reserved and
> should be zero, and the three highest bits of the major device class
> likewise. The management code should therefore test for this and return
> a proper "invalid params" error if the condition is not met.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/mgmt.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> index aaf9ce6..2785de2 100644
> --- a/net/bluetooth/mgmt.c
> +++ b/net/bluetooth/mgmt.c
> @@ -1430,6 +1430,12 @@ static int set_dev_class(struct sock *sk, struct hci_dev *hdev, void *data,
> goto unlock;
> }
>
> + if ((cp->minor & 0x03) != 0 || (cp->major & 0xe0) != 0) {
> + err = cmd_status(sk, hdev->id, MGMT_OP_SET_DEV_CLASS,
> + MGMT_STATUS_INVALID_PARAMS);
> + goto unlock;
> + }
we could do
if ((cp->minor & 0x03) || ...) {
However I am not sure what is preferred and I am fine both ways.
> +
> hdev->major_class = cp->major;
> hdev->minor_class = cp->minor;
>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox