2014-06-06 10:19:31

by Kiran Kumar Raparthy

[permalink] [raw]
Subject: [RFC] Bluetooth: Do not attempt to send dlci disconnect when in BT_CONFIG.

From: Nick Pelly <[email protected]>

Do not attempt to send dlci disconnect when in BT_CONFIG.

This fixes a bug where shutdown() and close() on a rfcomm socket during ACL
connection would not cause HCI Create Connection Cancel.

This is one of the number of patches from the Android AOSP common.git tree,
which is used on almost all Android devices. so I wanted to submit it for
review to see if it should go upstream.

Cc: Marcel Holtmann <[email protected]>
Cc: Gustavo Padovan <[email protected]>
Cc: Johan Hedberg <[email protected]>
Cc: David S. Miller <[email protected]>
Cc: Peter Hurley <[email protected]>
Cc: Seung-Woo Kim <[email protected]>
Cc: Nick Pelly <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: Android Kernel Team <[email protected]>
Cc: John Stultz <[email protected]>
Signed-off-by: Nick Pelly <[email protected]>
[kiran: Added context to commit message]
Signed-off-by: Kiran Raparthy <[email protected]>
---
net/bluetooth/rfcomm/core.c | 1 -
1 file changed, 1 deletion(-)

diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index cf62026..6a531e7 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -456,7 +456,6 @@ static int __rfcomm_dlc_close(struct rfcomm_dlc *d, int err)

switch (d->state) {
case BT_CONNECT:
- case BT_CONFIG:
case BT_OPEN:
case BT_CONNECT2:
if (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) {
--
1.8.2.1


2014-06-06 11:12:06

by Kiran Kumar Raparthy

[permalink] [raw]
Subject: Re: [RFC] Bluetooth: Do not attempt to send dlci disconnect when in BT_CONFIG.

Hi Marcel,
Below are the traces used by author for submitting patch previously.

[ 132.856414] rfcomm:rfcomm_sock_shutdown: sock c5cb3a20, sk c63fca00
[ 132.856933] rfcomm:__rfcomm_sock_close: sk c63fca00 state 5 socket c5cb3a20
[ 132.857788] rfcomm:__rfcomm_dlc_close: dlc c61ea240 state 7 dlci 38
err 0 session c63d4ba0
[ 132.858612] rfcomm:rfcomm_send_disc: c63d4ba0 dlci 38
[ 132.859069] rfcomm:rfcomm_send_frame: session c63d4ba0 len 4
[ 132.859893] l2cap:l2cap_sock_sendmsg: sock c5cb38c0, sk c63fc800
[ 132.860351] rfcomm:rfcomm_dlc_set_timer: dlc c61ea240 state 8 timeout 2000
[ 133.863739] rfcomm:rfcomm_sock_release: sock c5cb3a20, sk c63fca00
[ 133.864257] rfcomm:rfcomm_sock_shutdown: sock c5cb3a20, sk c63fca00
[ 133.865081] rfcomm:rfcomm_sock_kill: sk c63fca00 state 5 refcnt 2
[ 133.865539] rfcomm:rfcomm_sock_destruct: sk c63fca00 dlc c61ea240

Regards,
Kiran


On 6 June 2014 16:16, Marcel Holtmann <[email protected]> wrote:

> Hi Kiran,
>
> > Do not attempt to send dlci disconnect when in BT_CONFIG.
> >
> > This fixes a bug where shutdown() and close() on a rfcomm socket during
> ACL
> > connection would not cause HCI Create Connection Cancel.
> >
> > This is one of the number of patches from the Android AOSP common.git
> tree,
> > which is used on almost all Android devices. so I wanted to submit it
> for
> > review to see if it should go upstream.
> >
> > Cc: Marcel Holtmann <[email protected]>
> > Cc: Gustavo Padovan <[email protected]>
> > Cc: Johan Hedberg <[email protected]>
> > Cc: David S. Miller <[email protected]>
> > Cc: Peter Hurley <[email protected]>
> > Cc: Seung-Woo Kim <[email protected]>
> > Cc: Nick Pelly <[email protected]>
> > Cc: [email protected]
> > Cc: [email protected]
> > Cc: [email protected]
> > Cc: Android Kernel Team <[email protected]>
> > Cc: John Stultz <[email protected]>
> > Signed-off-by: Nick Pelly <[email protected]>
> > [kiran: Added context to commit message]
> > Signed-off-by: Kiran Raparthy <[email protected]>
> > ---
> > net/bluetooth/rfcomm/core.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
> > index cf62026..6a531e7 100644
> > --- a/net/bluetooth/rfcomm/core.c
> > +++ b/net/bluetooth/rfcomm/core.c
> > @@ -456,7 +456,6 @@ static int __rfcomm_dlc_close(struct rfcomm_dlc *d,
> int err)
> >
> > switch (d->state) {
> > case BT_CONNECT:
> > - case BT_CONFIG:
> > case BT_OPEN:
> > case BT_CONNECT2:
> > if (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) {
>
> you can include traces and a test program that will demonstrate this
> behavior. I am hearing about this one for the first time. Nobody else has
> indicated an issue like this before.
>
> Regards
>
> Marcel
>
>

2014-06-06 10:46:40

by Marcel Holtmann

[permalink] [raw]
Subject: Re: [RFC] Bluetooth: Do not attempt to send dlci disconnect when in BT_CONFIG.

Hi Kiran,

> Do not attempt to send dlci disconnect when in BT_CONFIG.
>
> This fixes a bug where shutdown() and close() on a rfcomm socket during ACL
> connection would not cause HCI Create Connection Cancel.
>
> This is one of the number of patches from the Android AOSP common.git tree,
> which is used on almost all Android devices. so I wanted to submit it for
> review to see if it should go upstream.
>
> Cc: Marcel Holtmann <[email protected]>
> Cc: Gustavo Padovan <[email protected]>
> Cc: Johan Hedberg <[email protected]>
> Cc: David S. Miller <[email protected]>
> Cc: Peter Hurley <[email protected]>
> Cc: Seung-Woo Kim <[email protected]>
> Cc: Nick Pelly <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> Cc: Android Kernel Team <[email protected]>
> Cc: John Stultz <[email protected]>
> Signed-off-by: Nick Pelly <[email protected]>
> [kiran: Added context to commit message]
> Signed-off-by: Kiran Raparthy <[email protected]>
> ---
> net/bluetooth/rfcomm/core.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
> index cf62026..6a531e7 100644
> --- a/net/bluetooth/rfcomm/core.c
> +++ b/net/bluetooth/rfcomm/core.c
> @@ -456,7 +456,6 @@ static int __rfcomm_dlc_close(struct rfcomm_dlc *d, int err)
>
> switch (d->state) {
> case BT_CONNECT:
> - case BT_CONFIG:
> case BT_OPEN:
> case BT_CONNECT2:
> if (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) {

you can include traces and a test program that will demonstrate this behavior. I am hearing about this one for the first time. Nobody else has indicated an issue like this before.

Regards

Marcel