Patch "Bluetooth: hidp: fix device disconnect on idle timeout" has been added to the 4.2-stable tree

This is a note to let you know that I've just added the patch titled

Bluetooth: hidp: fix device disconnect on idle timeout

to the 4.2-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
bluetooth-hidp-fix-device-disconnect-on-idle-timeout.patch
and it can be found in the queue-4.2 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From: David Herrmann <[email protected]>
Date: Mon, 7 Sep 2015 12:05:41 +0200
Subject: Bluetooth: hidp: fix device disconnect on idle timeout

From: David Herrmann <[email protected]>

commit 660f0fc07d21114549c1862e67e78b1cf0c90c29 upstream.

The HIDP specs define an idle-timeout which automatically disconnects a device. This has always been implemented in the HIDP layer and forced a synchronous shutdown of the hidp-scheduler. This works just fine, but lacks a forced disconnect on the underlying l2cap channels. This has been broken since:

commit 5205185d461d5902325e457ca80bd421127b7308
Author: David Herrmann <[email protected]>
Date: Sat Apr 6 20:28:47 2013 +0200

Bluetooth: hidp: remove old session-management

The old session-management always forced an l2cap error on the ctrl/intr channels when shutting down. The new session-management skips this, as we don't want to enforce channel policy on the caller. In other words, if user-space removes an HIDP device, the underlying channels (which are *owned* and *referenced* by user-space) are still left active. User-space needs to call shutdown(2) or close(2) to release them.

Unfortunately, this does not work with idle-timeouts. There is no way to signal user-space that the HIDP layer has been stopped. The API simply does not support any event-passing except for poll(2). Hence, we restore old behavior and force EUNATCH on the sockets if the HIDP layer is disconnected due to idle-timeouts (behavior of explicit disconnects remains unmodified). User-space can still call

    getsockopt(..., SO_ERROR, ...)

..to retrieve the EUNATCH error and clear sk_err. Hence, the channels can still be re-used (which nobody does so far, though). Therefore, the API still supports the new behavior, but with this patch it's also compatible to the old implicit channel shutdown.

---
 net/bluetooth/hidp/core.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

@@ -401,6 +401,20 @@ static void hidp_idle_timeout(unsigned l
 {
 	struct hidp_session *session = (struct hidp_session *) arg;
 
+	/* The HIDP user-space API only contains calls to add and remove
+	 * devices. There is no way to forward events of any kind. Therefore,
+	 * we have to forcefully disconnect a device on idle-timeouts. This is
+	 * unfortunate and weird API design, but it is spec-compliant and
+	 * required for backwards-compatibility. Hence, on idle-timeout, we
+	 * signal driver-detach events, so poll() will be woken up with an
+	 * error-condition on both sockets.
+	 */
+
+	session->intr_sock->sk->sk_err = EUNATCH;
+	session->ctrl_sock->sk->sk_err = EUNATCH;
+	wake_up_interruptible(sk_sleep(session->intr_sock->sk));
+	wake_up_interruptible(sk_sleep(session->ctrl_sock->sk));
+
 	hidp_session_terminate(session);
 }
 

Patches currently in stable-queue which might be from [email protected] are

queue-4.2/netlink-fix-locking-around-netlink_list_memberships.patch queue-4.2/bluetooth-hidp-fix-device-disconnect-on-idle-timeout.patch