Re: [Bluez-devel] "File descriptor in bad state" on sdp_connect()

Re: [Bluez-devel] "File descriptor in bad state" on sdp_connect()

[Peter Wippich]

Hi Marco, 

On Tue, 8 Aug 2006, Marco Pracucci wrote:

> Hi,
> 
> I have a problem with multiple concurrent calls to sdp_connect(). In
> particular, I have a simple application that search a service on
> different remote devices: the searches are done concurrently (until 7 in
> parallel), each from within a different pthread. I have experienced
> that, with a lot of Bluetooth dongles (example Surecom, D-Link), it
> occurs an "File descriptor in bad state" error. Debugging the
> sdp_connect() function I have founded that the error occurs on connect()
> system call.
> 
This problem has been discussed here several times for various 
applications. It is not related to SDP but to the general problem that 
(all ?) commercial available Bluetooth adaptors do not support multiple 
(concurrent) connection requests. The only solution is to serialize the 
connect requests. Until now nobody voluntered to do this in the kernel. 

Ciao, 

Peter 


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] "File descriptor in bad state" on sdp_connect()

[Fabrizio Guglielmino]

Hi,
I have had a similar problem ....I've discovered (with Marcel help) is a 
problem in l2cap layer.
l2cap kernel module do not handle multiple connect, Marcel send to me a 
patch I am trying to make to work
 but I'm very busy with my job and is not still clear where the patch 
hangs the system.

You can found some information searching in old messages....

Ciao
Fabrizio


Marco Pracucci ha scritto:
> Hi,
>
> I have a problem with multiple concurrent calls to sdp_connect(). In
> particular, I have a simple application that search a service on
> different remote devices: the searches are done concurrently (until 7 in
> parallel), each from within a different pthread. I have experienced
> that, with a lot of Bluetooth dongles (example Surecom, D-Link), it
> occurs an "File descriptor in bad state" error. Debugging the
> sdp_connect() function I have founded that the error occurs on connect()
> system call.
>
> Has anyone had a similar problem?
> Do you have any suggestion?
>
> Thanks,
> Marco Pracucci
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
>
>   


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] "File descriptor in bad state" on sdp_connect()

[Ulisses Furquim]

Hi Peter,

On 8/8/06, Peter Wippich <pewi@gw-instruments.de> wrote:
> > I have a problem with multiple concurrent calls to sdp_connect(). In
> > particular, I have a simple application that search a service on
> > different remote devices: the searches are done concurrently (until 7 in
> > parallel), each from within a different pthread. I have experienced
> > that, with a lot of Bluetooth dongles (example Surecom, D-Link), it
> > occurs an "File descriptor in bad state" error. Debugging the
> > sdp_connect() function I have founded that the error occurs on connect()
> > system call.
> >
> This problem has been discussed here several times for various
> applications. It is not related to SDP but to the general problem that
> (all ?) commercial available Bluetooth adaptors do not support multiple
> (concurrent) connection requests. The only solution is to serialize the
> connect requests. Until now nobody voluntered to do this in the kernel.

I'm working on this right now. I think I've found the problems with
that Marcel Holtmann's patch. I'm gonna test it a little bit more and
then I'll send the patch to the list. :-)

Regards,

-- Ulisses

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] "File descriptor in bad state" on sdp_connect()

[Marco Pracucci]

Hi,

I have a problem with multiple concurrent calls to sdp_connect(). In
particular, I have a simple application that search a service on
different remote devices: the searches are done concurrently (until 7 in
parallel), each from within a different pthread. I have experienced
that, with a lot of Bluetooth dongles (example Surecom, D-Link), it
occurs an "File descriptor in bad state" error. Debugging the
sdp_connect() function I have founded that the error occurs on connect()
system call.

Has anyone had a similar problem?
Do you have any suggestion?

Thanks,
Marco Pracucci


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] "File descriptor in bad state" on sdp_connect()

[Ulisses Furquim]

[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]

Hi Fabrizio,

On 8/8/06, Fabrizio Guglielmino <guglielmino@infitsrl.com> wrote:
> I have had a similar problem ....I've discovered (with Marcel help) is a
> problem in l2cap layer.
> l2cap kernel module do not handle multiple connect, Marcel send to me a
> patch I am trying to make to work
>  but I'm very busy with my job and is not still clear where the patch
> hangs the system.

We thought we had a deadlock somewhere but it wasn't the case. We had
two problems:

 - trying to list_del() the same list entry twice leading us to a page fault
 - we've forgotten to INIT_LIST_HEAD() our l2cap_conn->list leading us
to a NULL pointer dereference

I've done some modifications (and also included some bits from -mh)
and it seems to be working. However, I'm hitting a kernel bug at
kernel/timer.c inside cascade() from time to time. I haven't found
what is causing this yet, but the patch I'm sending is against 2.6.17
and I haven't tested with latest git snapshot so maybe this issue is
already fixed upstream (kernel/timer.c:cascade() was changed [1]).
Marcel, do you have any idea of what might be happening?

If anyone wants to give this beast a try you're warned that it might
lock up your system. FWIW, a quick test can be done using l2test from
CVS like:

  $ ./l2test -m bd_addr1 bd_addr2 ...

Best regards,

-- Ulisses


[1] http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;h=b650f04888ed6dbc6abb07adcee5c58a8f27c374;hp=9062a82ee8ec40d9a6ef985c625bd8daaf5778c5;hb=a2c348fe0117adced11e374329a5ea3f7c43cb41;f=kernel/timer.c

[-- Attachment #2: l2cap-handle-multiple-connects.patch --]
[-- Type: text/x-patch, Size: 5007 bytes --]

diff -urN linux-2.6.17/include/net/bluetooth/l2cap.h linux-2.6.17-dev/include/net/bluetooth/l2cap.h
--- linux-2.6.17/include/net/bluetooth/l2cap.h	2006-06-17 22:49:35.000000000 -0300
+++ linux-2.6.17-dev/include/net/bluetooth/l2cap.h	2006-08-07 17:05:49.000000000 -0300
@@ -183,6 +183,8 @@
 };
 
 struct l2cap_conn {
+	struct list_head list;
+
 	struct hci_conn	*hcon;
 
 	bdaddr_t	*dst;
diff -urN linux-2.6.17/net/bluetooth/l2cap.c linux-2.6.17-dev/net/bluetooth/l2cap.c
--- linux-2.6.17/net/bluetooth/l2cap.c	2006-06-17 22:49:35.000000000 -0300
+++ linux-2.6.17-dev/net/bluetooth/l2cap.c	2006-08-08 17:23:44.000000000 -0300
@@ -69,6 +69,9 @@
 static void __l2cap_chan_add(struct l2cap_conn *conn, struct sock *sk, struct sock *parent);
 static void l2cap_chan_del(struct sock *sk, int err);
 
+static LIST_HEAD(l2cap_conn_list);
+static DEFINE_SPINLOCK(l2cap_conn_lock);
+
 static void __l2cap_sock_close(struct sock *sk, int reason);
 static void l2cap_sock_close(struct sock *sk);
 static void l2cap_sock_kill(struct sock *sk);
@@ -135,6 +138,8 @@
 	spin_lock_init(&conn->lock);
 	rwlock_init(&conn->chan_list.lock);
 
+	INIT_LIST_HEAD(&conn->list);
+
 	BT_DBG("hcon %p conn %p", hcon, conn);
 	return conn;
 }
@@ -168,9 +173,9 @@
 static inline void l2cap_chan_add(struct l2cap_conn *conn, struct sock *sk, struct sock *parent)
 {
 	struct l2cap_chan_list *l = &conn->chan_list;
-	write_lock(&l->lock);
+	write_lock_bh(&l->lock);
 	__l2cap_chan_add(conn, sk, parent);
-	write_unlock(&l->lock);
+	write_unlock_bh(&l->lock);
 }
 
 static inline u8 l2cap_get_ident(struct l2cap_conn *conn)
@@ -183,14 +188,14 @@
 	 *  200 - 254 are used by utilities like l2ping, etc.
 	 */
 
-	spin_lock(&conn->lock);
+	spin_lock_bh(&conn->lock);
 
 	if (++conn->tx_ident > 128)
 		conn->tx_ident = 1;
 
 	id = conn->tx_ident;
 
-	spin_unlock(&conn->lock);
+	spin_unlock_bh(&conn->lock);
 
 	return id;
 }
@@ -497,18 +502,23 @@
 	sk->sk_state = BT_CONNECT;
 	l2cap_sock_set_timer(sk, sk->sk_sndtimeo);
 
-	if (hcon->state == BT_CONNECTED) {
-		if (sk->sk_type == SOCK_SEQPACKET) {
-			struct l2cap_conn_req req;
-			l2cap_pi(sk)->ident = l2cap_get_ident(conn);
-			req.scid = __cpu_to_le16(l2cap_pi(sk)->scid);
-			req.psm  = l2cap_pi(sk)->psm;
-			l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
-					L2CAP_CONN_REQ, sizeof(req), &req);
-		} else {
-			l2cap_sock_clear_timer(sk);
-			sk->sk_state = BT_CONNECTED;
-		}
+	if (hcon->state != BT_CONNECTED) {
+		spin_lock(&l2cap_conn_lock);
+		list_add_tail(&conn->list, &l2cap_conn_list);
+		spin_unlock(&l2cap_conn_lock);
+		goto done;
+	}
+
+	if (sk->sk_type == SOCK_SEQPACKET) {
+		struct l2cap_conn_req req;
+		l2cap_pi(sk)->ident = l2cap_get_ident(conn);
+		req.scid = __cpu_to_le16(l2cap_pi(sk)->scid);
+		req.psm  = l2cap_pi(sk)->psm;
+		l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
+				L2CAP_CONN_REQ, sizeof(req), &req);
+	} else {
+		l2cap_sock_clear_timer(sk);
+		sk->sk_state = BT_CONNECTED;
 	}
 
 done:
@@ -1007,7 +1017,7 @@
 {
 	struct sock *next = l2cap_pi(sk)->next_c, *prev = l2cap_pi(sk)->prev_c;
 
-	write_lock(&l->lock);
+	write_lock_bh(&l->lock);
 	if (sk == l->head)
 		l->head = next;
 
@@ -1015,7 +1025,7 @@
 		l2cap_pi(next)->prev_c = prev;
 	if (prev)
 		l2cap_pi(prev)->next_c = next;
-	write_unlock(&l->lock);
+	write_unlock_bh(&l->lock);
 
 	__sock_put(sk);
 }
@@ -1425,11 +1435,11 @@
 	if (!sk)
 		goto response;
 
-	write_lock(&list->lock);
+	write_lock_bh(&list->lock);
 
 	/* Check if we already have channel with that dcid */
 	if (__l2cap_get_chan_by_dcid(list, scid)) {
-		write_unlock(&list->lock);
+		write_unlock_bh(&list->lock);
 		sock_set_flag(sk, SOCK_ZAPPED);
 		l2cap_sock_kill(sk);
 		goto response;
@@ -1467,7 +1477,7 @@
 	result = status = 0;
 
 done:
-	write_unlock(&list->lock);
+	write_unlock_bh(&list->lock);
 
 response:
 	bh_unlock_sock(parent);
@@ -1926,19 +1936,47 @@
 
 static int l2cap_connect_cfm(struct hci_conn *hcon, u8 status)
 {
+	struct l2cap_conn *conn;
+
 	BT_DBG("hcon %p bdaddr %s status %d", hcon, batostr(&hcon->dst), status);
 
 	if (hcon->type != ACL_LINK)
 		return 0;
 
-	if (!status) {
-		struct l2cap_conn *conn;
-
+	switch (status) {
+	case 0x00:
 		conn = l2cap_conn_add(hcon, status);
-		if (conn)
-			l2cap_conn_ready(conn);
-	} else 
+		if (!conn)
+			break;
+
+		spin_lock_bh(&l2cap_conn_lock);
+		list_del(&conn->list);
+		spin_unlock_bh(&l2cap_conn_lock);
+
+		l2cap_conn_ready(conn);
+
+		spin_lock_bh(&l2cap_conn_lock);
+		if (!list_empty(&l2cap_conn_list)) {
+			struct l2cap_conn *next;
+			next = list_entry(l2cap_conn_list.next, struct l2cap_conn, list);
+			list_move_tail(&next->list, &l2cap_conn_list);
+			hci_conn_put(next->hcon);
+			hci_connect(next->hcon->hdev, ACL_LINK, next->dst);
+		}
+		spin_unlock_bh(&l2cap_conn_lock);
+		break;
+
+	case 0x0c:
+		break;
+
+	default:
+		spin_lock_bh(&l2cap_conn_lock);
+		if ((conn = hcon->l2cap_data))
+			list_del(&conn->list);
+		spin_unlock_bh(&l2cap_conn_lock);
 		l2cap_conn_del(hcon, bt_err(status));
+		break;
+	}
 
 	return 0;
 }

Re: [Bluez-devel] "File descriptor in bad state" on sdp_connect()

[Ulisses Furquim]

[-- Attachment #1: Type: text/plain, Size: 656 bytes --]

Hi Marcel,

On 8/9/06, Marcel Holtmann <marcel@holtmann.org> wrote:
> > I've done some modifications (and also included some bits from -mh)
> > and it seems to be working. However, I'm hitting a kernel bug at
> > kernel/timer.c inside cascade() from time to time. I haven't found
> > what is causing this yet, but the patch I'm sending is against 2.6.17
> > and I haven't tested with latest git snapshot so maybe this issue is
> > already fixed upstream (kernel/timer.c:cascade() was changed [1]).
>
> please redo the patch against 2.6.18-rc4 and I will do some additional
> testing.

Done. Here is the same patch against 2.6.18-rc4.

Regards,

-- Ulisses

[-- Attachment #2: l2cap-handle-multiple-connects-2.6.18-rc4.patch --]
[-- Type: text/x-patch, Size: 3114 bytes --]

diff -urN linux-2.6.18-rc4/include/net/bluetooth/l2cap.h linux-2.6.18-rc4-dev/include/net/bluetooth/l2cap.h
--- linux-2.6.18-rc4/include/net/bluetooth/l2cap.h	2006-06-17 22:49:35.000000000 -0300
+++ linux-2.6.18-rc4-dev/include/net/bluetooth/l2cap.h	2006-08-09 18:04:26.000000000 -0300
@@ -183,6 +183,8 @@
 };
 
 struct l2cap_conn {
+	struct list_head list;
+
 	struct hci_conn	*hcon;
 
 	bdaddr_t	*dst;
diff -urN linux-2.6.18-rc4/net/bluetooth/l2cap.c linux-2.6.18-rc4-dev/net/bluetooth/l2cap.c
--- linux-2.6.18-rc4/net/bluetooth/l2cap.c	2006-08-09 18:28:31.000000000 -0300
+++ linux-2.6.18-rc4-dev/net/bluetooth/l2cap.c	2006-08-09 18:26:06.000000000 -0300
@@ -63,6 +63,9 @@
 	.lock = RW_LOCK_UNLOCKED
 };
 
+static LIST_HEAD(l2cap_conn_list);
+static DEFINE_SPINLOCK(l2cap_conn_lock);
+
 static void __l2cap_sock_close(struct sock *sk, int reason);
 static void l2cap_sock_close(struct sock *sk);
 static void l2cap_sock_kill(struct sock *sk);
@@ -282,6 +285,8 @@
 	spin_lock_init(&conn->lock);
 	rwlock_init(&conn->chan_list.lock);
 
+	INIT_LIST_HEAD(&conn->list);
+
 	return conn;
 }
 
@@ -642,18 +647,23 @@
 	sk->sk_state = BT_CONNECT;
 	l2cap_sock_set_timer(sk, sk->sk_sndtimeo);
 
-	if (hcon->state == BT_CONNECTED) {
-		if (sk->sk_type == SOCK_SEQPACKET) {
-			struct l2cap_conn_req req;
-			l2cap_pi(sk)->ident = l2cap_get_ident(conn);
-			req.scid = __cpu_to_le16(l2cap_pi(sk)->scid);
-			req.psm  = l2cap_pi(sk)->psm;
-			l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
-					L2CAP_CONN_REQ, sizeof(req), &req);
-		} else {
-			l2cap_sock_clear_timer(sk);
-			sk->sk_state = BT_CONNECTED;
-		}
+	if (hcon->state != BT_CONNECTED) {
+		spin_lock(&l2cap_conn_lock);
+		list_add_tail(&conn->list, &l2cap_conn_list);
+		spin_unlock(&l2cap_conn_lock);
+		goto done;
+	}
+
+	if (sk->sk_type == SOCK_SEQPACKET) {
+		struct l2cap_conn_req req;
+		l2cap_pi(sk)->ident = l2cap_get_ident(conn);
+		req.scid = __cpu_to_le16(l2cap_pi(sk)->scid);
+		req.psm  = l2cap_pi(sk)->psm;
+		l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
+				L2CAP_CONN_REQ, sizeof(req), &req);
+	} else {
+		l2cap_sock_clear_timer(sk);
+		sk->sk_state = BT_CONNECTED;
 	}
 
 done:
@@ -1926,12 +1936,40 @@
 	if (hcon->type != ACL_LINK)
 		return 0;
 
-	if (!status) {
+	switch (status) {
+	case 0x00:
 		conn = l2cap_conn_add(hcon, status);
-		if (conn)
-			l2cap_conn_ready(conn);
-	} else
+		if (!conn)
+			break;
+
+		spin_lock_bh(&l2cap_conn_lock);
+		list_del(&conn->list);
+		spin_unlock_bh(&l2cap_conn_lock);
+
+		l2cap_conn_ready(conn);
+
+		spin_lock_bh(&l2cap_conn_lock);
+		if (!list_empty(&l2cap_conn_list)) {
+			struct l2cap_conn *next;
+			next = list_entry(l2cap_conn_list.next, struct l2cap_conn, list);
+			list_move_tail(&next->list, &l2cap_conn_list);
+			hci_conn_put(next->hcon);
+			hci_connect(next->hcon->hdev, ACL_LINK, next->dst);
+		}
+		spin_unlock_bh(&l2cap_conn_lock);
+		break;
+
+	case 0x0c:
+		break;
+
+	default:
+		spin_lock_bh(&l2cap_conn_lock);
+		if ((conn = hcon->l2cap_data))
+			list_del(&conn->list);
+		spin_unlock_bh(&l2cap_conn_lock);
 		l2cap_conn_del(hcon, bt_err(status));
+		break;
+	}
 
 	return 0;
 }

Re: [Bluez-devel] "File descriptor in bad state" on sdp_connect()

[Marcel Holtmann]

Hi Ulisses,

> > I have had a similar problem ....I've discovered (with Marcel help) is a
> > problem in l2cap layer.
> > l2cap kernel module do not handle multiple connect, Marcel send to me a
> > patch I am trying to make to work
> >  but I'm very busy with my job and is not still clear where the patch
> > hangs the system.
> 
> We thought we had a deadlock somewhere but it wasn't the case. We had
> two problems:
> 
>  - trying to list_del() the same list entry twice leading us to a page fault
>  - we've forgotten to INIT_LIST_HEAD() our l2cap_conn->list leading us
> to a NULL pointer dereference
> 
> I've done some modifications (and also included some bits from -mh)
> and it seems to be working. However, I'm hitting a kernel bug at
> kernel/timer.c inside cascade() from time to time. I haven't found
> what is causing this yet, but the patch I'm sending is against 2.6.17
> and I haven't tested with latest git snapshot so maybe this issue is
> already fixed upstream (kernel/timer.c:cascade() was changed [1]).

please redo the patch against 2.6.18-rc4 and I will do some additional
testing.

Regards

Marcel



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] "File descriptor in bad state" on sdp_connect()

[Marcel Holtmann]

Hi Ulisses,

> > > I've done some modifications (and also included some bits from -mh)
> > > and it seems to be working. However, I'm hitting a kernel bug at
> > > kernel/timer.c inside cascade() from time to time. I haven't found
> > > what is causing this yet, but the patch I'm sending is against 2.6.17
> > > and I haven't tested with latest git snapshot so maybe this issue is
> > > already fixed upstream (kernel/timer.c:cascade() was changed [1]).
> >
> > please redo the patch against 2.6.18-rc4 and I will do some additional
> > testing.
> 
> Done. Here is the same patch against 2.6.18-rc4.

I tested this patch on my Quad G5. I don't see any timer issues, but it
also doesn't work either.

Regards

Marcel



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] "File descriptor in bad state" on sdp_connect()

[Ulisses Furquim]

Hi Marcel,

On 8/9/06, Marcel Holtmann <marcel@holtmann.org> wrote:
> > > please redo the patch against 2.6.18-rc4 and I will do some additional
> > > testing.
> >
> > Done. Here is the same patch against 2.6.18-rc4.
>
> I tested this patch on my Quad G5. I don't see any timer issues, but it
> also doesn't work either.

Damn it. You don't have an HCI dump while l2test is running, do you?
(or even l2test output, debug messages..). Thanks.

Regards,

-- Ulisses

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] "File descriptor in bad state" on sdp_connect()

[Marcel Holtmann]

Hi Ulisses,

> > > > please redo the patch against 2.6.18-rc4 and I will do some additional
> > > > testing.
> > >
> > > Done. Here is the same patch against 2.6.18-rc4.
> >
> > I tested this patch on my Quad G5. I don't see any timer issues, but it
> > also doesn't work either.
> 
> Damn it. You don't have an HCI dump while l2test is running, do you?
> (or even l2test output, debug messages..). Thanks.

now my machine freezed when I tried to get a hcidump for you. However I
remember seeing the Command Disallowed error and after the Connect
Complete, I didn't see the additional Create Connection.

Regards

Marcel



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] "File descriptor in bad state" on sdp_connect()

[Ulisses Furquim]

Hi Marcel,

On 8/10/06, Marcel Holtmann <marcel@holtmann.org> wrote:
> >  - trying to list_del() the same list entry twice leading us to a page fault
>
> where do we delete the entry twice?

On the first version of the patch (the one you sent to the list) there
was a list_del() inside l2cap_conn_del(). This list_del() was causing
a page fault trying to dereference prev and next pointers that were
poisoned because of a previous list_del().

> >  - we've forgotten to INIT_LIST_HEAD() our l2cap_conn->list leading us
> > to a NULL pointer dereference
>
> This must be another bug, because it is not needed to init the list item
> itself. You only have to init the list head.

Hmm.. I think you're right as we already declare our list head with
LIST_HEAD(). I was seeing a NULL pointer dereference inside
list_del(), tough. Weird.

> The attached patch should not change any behavior, but keep track of
> L2CAP connections in creation state. Please test and check the output of
> dmesg.

Ok.

-- Ulisses

Re: [Bluez-devel] "File descriptor in bad state" on sdp_connect()

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

Hi Ulisses,

> > I have had a similar problem ....I've discovered (with Marcel help) is a
> > problem in l2cap layer.
> > l2cap kernel module do not handle multiple connect, Marcel send to me a
> > patch I am trying to make to work
> >  but I'm very busy with my job and is not still clear where the patch
> > hangs the system.
> 
> We thought we had a deadlock somewhere but it wasn't the case. We had
> two problems:
> 
>  - trying to list_del() the same list entry twice leading us to a page fault

where do we delete the entry twice?

>  - we've forgotten to INIT_LIST_HEAD() our l2cap_conn->list leading us
> to a NULL pointer dereference

This must be another bug, because it is not needed to init the list item
itself. You only have to init the list head.

The attached patch should not change any behavior, but keep track of
L2CAP connections in creation state. Please test and check the output of
dmesg.

Regards

Marcel


[-- Attachment #2: patch --]
[-- Type: text/x-patch, Size: 3565 bytes --]

diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 8242a0e..cb19e66 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -183,6 +183,8 @@ struct l2cap_chan_list {
 };
 
 struct l2cap_conn {
+	struct list_head list;
+
 	struct hci_conn	*hcon;
 
 	bdaddr_t	*dst;
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index d56f60b..1fd3060 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -55,7 +55,7 @@ #undef  BT_DBG
 #define BT_DBG(D...)
 #endif
 
-#define VERSION "2.8"
+#define VERSION "2.9"
 
 static const struct proto_ops l2cap_sock_ops;
 
@@ -63,6 +63,9 @@ static struct bt_sock_list l2cap_sk_list
 	.lock = RW_LOCK_UNLOCKED
 };
 
+static LIST_HEAD(l2cap_conn_list);
+static DEFINE_SPINLOCK(l2cap_conn_lock);
+
 static void __l2cap_sock_close(struct sock *sk, int reason);
 static void l2cap_sock_close(struct sock *sk);
 static void l2cap_sock_kill(struct sock *sk);
@@ -642,18 +645,23 @@ static int l2cap_do_connect(struct sock 
 	sk->sk_state = BT_CONNECT;
 	l2cap_sock_set_timer(sk, sk->sk_sndtimeo);
 
-	if (hcon->state == BT_CONNECTED) {
-		if (sk->sk_type == SOCK_SEQPACKET) {
-			struct l2cap_conn_req req;
-			l2cap_pi(sk)->ident = l2cap_get_ident(conn);
-			req.scid = __cpu_to_le16(l2cap_pi(sk)->scid);
-			req.psm  = l2cap_pi(sk)->psm;
-			l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
-					L2CAP_CONN_REQ, sizeof(req), &req);
-		} else {
-			l2cap_sock_clear_timer(sk);
-			sk->sk_state = BT_CONNECTED;
-		}
+	if (hcon->state != BT_CONNECTED) {
+		spin_lock_bh(&l2cap_conn_lock);
+		list_add_tail(&conn->list, &l2cap_conn_list);
+		spin_unlock_bh(&l2cap_conn_lock);
+		goto done;
+	}
+
+	if (sk->sk_type == SOCK_SEQPACKET) {
+		struct l2cap_conn_req req;
+		l2cap_pi(sk)->ident = l2cap_get_ident(conn);
+		req.scid = __cpu_to_le16(l2cap_pi(sk)->scid);
+		req.psm  = l2cap_pi(sk)->psm;
+		l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
+				L2CAP_CONN_REQ, sizeof(req), &req);
+	} else {
+		l2cap_sock_clear_timer(sk);
+		sk->sk_state = BT_CONNECTED;
 	}
 
 done:
@@ -1920,18 +1928,60 @@ static int l2cap_connect_ind(struct hci_
 static int l2cap_connect_cfm(struct hci_conn *hcon, u8 status)
 {
 	struct l2cap_conn *conn;
+	struct list_head *p;
 
 	BT_DBG("hcon %p bdaddr %s status %d", hcon, batostr(&hcon->dst), status);
 
 	if (hcon->type != ACL_LINK)
 		return 0;
 
-	if (!status) {
+	spin_lock_bh(&l2cap_conn_lock);
+	list_for_each(p, &l2cap_conn_list) {
+		struct l2cap_conn *c = list_entry(p, struct l2cap_conn, list);
+		BT_ERR("src %s dst %s", batostr(c->src), batostr(c->dst));
+	}
+	spin_unlock_bh(&l2cap_conn_lock);
+
+	switch (status) {
+	case 0x00:
 		conn = l2cap_conn_add(hcon, status);
-		if (conn)
-			l2cap_conn_ready(conn);
-	} else
+		if (!conn)
+			break;
+
+		spin_lock_bh(&l2cap_conn_lock);
+		list_del(&conn->list);
+		spin_unlock_bh(&l2cap_conn_lock);
+
+		l2cap_conn_ready(conn);
+
+#if 0
+		spin_lock_bh(&l2cap_conn_lock);
+		if (!list_empty(&l2cap_conn_list)) {
+			struct l2cap_conn *next;
+			next = list_entry(l2cap_conn_list.next, struct l2cap_conn, list);
+			list_move_tail(&next->list, &l2cap_conn_list);
+			hci_conn_put(next->hcon);
+			hci_connect(next->hcon->hdev, ACL_LINK, next->dst);
+		}
+		spin_unlock_bh(&l2cap_conn_lock);
+#endif
+		break;
+
+	case 0x0c:
+		/* fall-through for now */
+
+	default:
+		conn = hcon->l2cap_data;
+		if (!conn)
+			break;
+
+		spin_lock_bh(&l2cap_conn_lock);
+		list_del(&conn->list);
+		spin_unlock_bh(&l2cap_conn_lock);
+
 		l2cap_conn_del(hcon, bt_err(status));
+		break;
+	}
 
 	return 0;
 }

[-- Attachment #3: Type: text/plain, Size: 373 bytes --]

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #4: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] "File descriptor in bad state" on sdp_connect()

[Ulisses Furquim]

Hi Marcel,

On 8/10/06, Marcel Holtmann <marcel@holtmann.org> wrote:
> The attached patch should not change any behavior, but keep track of
> L2CAP connections in creation state. Please test and check the output of
> dmesg.

Hmm.. actually it changes the behavior a little bit. This part:

	default:
		conn = hcon->l2cap_data;
		if (!conn)
			break;

		spin_lock_bh(&l2cap_conn_lock);
		list_del(&conn->list);
		spin_unlock_bh(&l2cap_conn_lock);

 		l2cap_conn_del(hcon, bt_err(status));
		break;

should be like the following code. Otherwise we end up not calling
l2cap_conn_del() on hcon, right? (or am I missing anything?)

       default:
               if ((conn = hcon->l2cap_data)) {
                       spin_lock_bh(&l2cap_conn_lock);
                       list_del(&conn->list);
                       spin_unlock_bh(&l2cap_conn_lock);
               }
               l2cap_conn_del(hcon, bt_err(status));
               break;

Best regards,

-- Ulisses

Re: [Bluez-devel] "File descriptor in bad state" on sdp_connect()

[Ulisses Furquim]

On 8/11/06, Marcel Holtmann <marcel@holtmann.org> wrote:
> look into l2cap_conn_del() and check what happens if l2cap_data is NULL.
> This doesn't change the behavior.

Doooh. Right. We shouldn't be calling l2cap_conn_del() at all if
l2cap_data is NULL so it doesn't change any behavior and we actually
save one function call. :-)

Regards,

-- Ulisses

Re: [Bluez-devel] "File descriptor in bad state" on sdp_connect()

[Marcel Holtmann]

Hi Ulisses,

> > The attached patch should not change any behavior, but keep track of
> > L2CAP connections in creation state. Please test and check the output of
> > dmesg.
> 
> Hmm.. actually it changes the behavior a little bit. This part:
> 
> 	default:
> 		conn = hcon->l2cap_data;
> 		if (!conn)
> 			break;
> 
> 		spin_lock_bh(&l2cap_conn_lock);
> 		list_del(&conn->list);
> 		spin_unlock_bh(&l2cap_conn_lock);
> 
>  		l2cap_conn_del(hcon, bt_err(status));
> 		break;
> 
> should be like the following code. Otherwise we end up not calling
> l2cap_conn_del() on hcon, right? (or am I missing anything?)
> 
>        default:
>                if ((conn = hcon->l2cap_data)) {
>                        spin_lock_bh(&l2cap_conn_lock);
>                        list_del(&conn->list);
>                        spin_unlock_bh(&l2cap_conn_lock);
>                }
>                l2cap_conn_del(hcon, bt_err(status));
>                break;

look into l2cap_conn_del() and check what happens if l2cap_data is NULL.
This doesn't change the behavior.

Regards

Marcel



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] "File descriptor in bad state" on sdp_connect()

[Fabrizio Guglielmino]

Hi Ulisses,
I have been outside for a few days...and now I'm reading all the mail  
about sdp_connect problem.
if I find the time I install the patch on a development system so I  
try to contribute to the final version.

bye


Il giorno 11/ago/06, alle ore 22:09, Ulisses Furquim ha scritto:

> On 8/11/06, Marcel Holtmann <marcel@holtmann.org> wrote:
>> look into l2cap_conn_del() and check what happens if l2cap_data is  
>> NULL.
>> This doesn't change the behavior.
>
> Doooh. Right. We shouldn't be calling l2cap_conn_del() at all if
> l2cap_data is NULL so it doesn't change any behavior and we actually
> save one function call. :-)
>
> Regards,
>
> -- Ulisses
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel