[RESEND PATCH v4 1/3] Bluetooth: bnep: fix possible might sleep error in bnep_session

[RESEND PATCH v4 1/3] Bluetooth: bnep: fix possible might sleep error in bnep_session

[Jeffy Chen]

It looks like bnep_session has same pattern as the issue reported in
old rfcomm:

	while (1) {
		set_current_state(TASK_INTERRUPTIBLE);
		if (condition)
			break;
		// may call might_sleep here
		schedule();
	}
	__set_current_state(TASK_RUNNING);

Which fixed at:
	dfb2fae Bluetooth: Fix nested sleeps

So let's fix it at the same way, also follow the suggestion of:
https://lwn.net/Articles/628628/

Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: AL Yu-Chen Cho <acho@suse.com>
---

Changes in v4: None
Changes in v2: None

 net/bluetooth/bnep/core.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/net/bluetooth/bnep/core.c b/net/bluetooth/bnep/core.c
index fbf251f..4d6b94d 100644
--- a/net/bluetooth/bnep/core.c
+++ b/net/bluetooth/bnep/core.c
@@ -484,16 +484,16 @@ static int bnep_session(void *arg)
 	struct net_device *dev = s->dev;
 	struct sock *sk = s->sock->sk;
 	struct sk_buff *skb;
-	wait_queue_t wait;
+	DEFINE_WAIT_FUNC(wait, woken_wake_function);
 
 	BT_DBG("");
 
 	set_user_nice(current, -15);
 
-	init_waitqueue_entry(&wait, current);
 	add_wait_queue(sk_sleep(sk), &wait);
 	while (1) {
-		set_current_state(TASK_INTERRUPTIBLE);
+		/* Ensure session->terminate is updated */
+		smp_mb__before_atomic();
 
 		if (atomic_read(&s->terminate))
 			break;
@@ -515,9 +515,8 @@ static int bnep_session(void *arg)
 				break;
 		netif_wake_queue(dev);
 
-		schedule();
+		wait_woken(&wait, TASK_INTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT);
 	}
-	__set_current_state(TASK_RUNNING);
 	remove_wait_queue(sk_sleep(sk), &wait);
 
 	/* Cleanup session */
@@ -666,7 +665,7 @@ int bnep_del_connection(struct bnep_conndel_req *req)
 	s = __bnep_get_session(req->dst);
 	if (s) {
 		atomic_inc(&s->terminate);
-		wake_up_process(s->task);
+		wake_up_interruptible(sk_sleep(s->sock->sk));
 	} else
 		err = -ENOENT;
 
-- 
2.1.4

[RESEND PATCH v4 2/3] Bluetooth: cmtp: fix possible might sleep error in cmtp_session

[Jeffy Chen]

It looks like cmtp_session has same pattern as the issue reported in
old rfcomm:

	while (1) {
		set_current_state(TASK_INTERRUPTIBLE);
		if (condition)
			break;
		// may call might_sleep here
		schedule();
	}
	__set_current_state(TASK_RUNNING);

Which fixed at:
	dfb2fae Bluetooth: Fix nested sleeps

So let's fix it at the same way, also follow the suggestion of:
https://lwn.net/Articles/628628/

Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: AL Yu-Chen Cho <acho@suse.com>

---

Changes in v4: None
Changes in v2:
Remove unnecessary memory barrier before wake_up_* functions.

 net/bluetooth/cmtp/core.c | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/net/bluetooth/cmtp/core.c b/net/bluetooth/cmtp/core.c
index 9e59b66..1152ce3 100644
--- a/net/bluetooth/cmtp/core.c
+++ b/net/bluetooth/cmtp/core.c
@@ -280,16 +280,16 @@ static int cmtp_session(void *arg)
 	struct cmtp_session *session = arg;
 	struct sock *sk = session->sock->sk;
 	struct sk_buff *skb;
-	wait_queue_t wait;
+	DEFINE_WAIT_FUNC(wait, woken_wake_function);
 
 	BT_DBG("session %p", session);
 
 	set_user_nice(current, -15);
 
-	init_waitqueue_entry(&wait, current);
 	add_wait_queue(sk_sleep(sk), &wait);
 	while (1) {
-		set_current_state(TASK_INTERRUPTIBLE);
+		/* Ensure session->terminate is updated */
+		smp_mb__before_atomic();
 
 		if (atomic_read(&session->terminate))
 			break;
@@ -306,9 +306,8 @@ static int cmtp_session(void *arg)
 
 		cmtp_process_transmit(session);
 
-		schedule();
+		wait_woken(&wait, TASK_INTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT);
 	}
-	__set_current_state(TASK_RUNNING);
 	remove_wait_queue(sk_sleep(sk), &wait);
 
 	down_write(&cmtp_session_sem);
@@ -393,7 +392,7 @@ int cmtp_add_connection(struct cmtp_connadd_req *req, struct socket *sock)
 		err = cmtp_attach_device(session);
 		if (err < 0) {
 			atomic_inc(&session->terminate);
-			wake_up_process(session->task);
+			wake_up_interruptible(sk_sleep(session->sock->sk));
 			up_write(&cmtp_session_sem);
 			return err;
 		}
@@ -431,7 +430,11 @@ int cmtp_del_connection(struct cmtp_conndel_req *req)
 
 		/* Stop session thread */
 		atomic_inc(&session->terminate);
-		wake_up_process(session->task);
+
+		/* Ensure session->terminate is updated */
+		smp_mb__after_atomic();
+
+		wake_up_interruptible(sk_sleep(session->sock->sk));
 	} else
 		err = -ENOENT;
 
-- 
2.1.4

[RESEND PATCH v4 3/3] Bluetooth: hidp: fix possible might sleep error in hidp_session_thread

[Jeffy Chen]

It looks like hidp_session_thread has same pattern as the issue reported in
old rfcomm:

	while (1) {
		set_current_state(TASK_INTERRUPTIBLE);
		if (condition)
			break;
		// may call might_sleep here
		schedule();
	}
	__set_current_state(TASK_RUNNING);

Which fixed at:
	dfb2fae Bluetooth: Fix nested sleeps

So let's fix it at the same way, also follow the suggestion of:
https://lwn.net/Articles/628628/

Signed-off-by: Jeffy Chen <jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Tested-by: AL Yu-Chen Cho <acho-IBi9RG/b67k@public.gmane.org>
Tested-by: Rohit Vaswani <rvaswani-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

---

Changes in v4:
1/ Make hidp_session_wake_function static.
2/ Remove unnecessary default_wake_function.

Changes in v2:
1/ Fix could not wake up by wake attempts on original wait queues.
2/ Remove unnecessary memory barrier before wake_up_* functions.

 net/bluetooth/hidp/core.c | 33 ++++++++++++++++++++++-----------
 1 file changed, 22 insertions(+), 11 deletions(-)

diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index 0bec458..1fc0764 100644
--- a/net/bluetooth/hidp/core.c
+++ b/net/bluetooth/hidp/core.c
@@ -36,6 +36,7 @@
 #define VERSION "1.2"
 
 static DECLARE_RWSEM(hidp_session_sem);
+static DECLARE_WAIT_QUEUE_HEAD(hidp_session_wq);
 static LIST_HEAD(hidp_session_list);
 
 static unsigned char hidp_keycode[256] = {
@@ -1068,12 +1069,12 @@ static int hidp_session_start_sync(struct hidp_session *session)
  * Wake up session thread and notify it to stop. This is asynchronous and
  * returns immediately. Call this whenever a runtime error occurs and you want
  * the session to stop.
- * Note: wake_up_process() performs any necessary memory-barriers for us.
+ * Note: wake_up_interruptible() performs any necessary memory-barriers for us.
  */
 static void hidp_session_terminate(struct hidp_session *session)
 {
 	atomic_inc(&session->terminate);
-	wake_up_process(session->task);
+	wake_up_interruptible(&hidp_session_wq);
 }
 
 /*
@@ -1180,7 +1181,9 @@ static void hidp_session_run(struct hidp_session *session)
 	struct sock *ctrl_sk = session->ctrl_sock->sk;
 	struct sock *intr_sk = session->intr_sock->sk;
 	struct sk_buff *skb;
+	DEFINE_WAIT_FUNC(wait, woken_wake_function);
 
+	add_wait_queue(&hidp_session_wq, &wait);
 	for (;;) {
 		/*
 		 * This thread can be woken up two ways:
@@ -1188,12 +1191,10 @@ static void hidp_session_run(struct hidp_session *session)
 		 *    session->terminate flag and wakes this thread up.
 		 *  - Via modifying the socket state of ctrl/intr_sock. This
 		 *    thread is woken up by ->sk_state_changed().
-		 *
-		 * Note: set_current_state() performs any necessary
-		 * memory-barriers for us.
 		 */
-		set_current_state(TASK_INTERRUPTIBLE);
 
+		/* Ensure session->terminate is updated */
+		smp_mb__before_atomic();
 		if (atomic_read(&session->terminate))
 			break;
 
@@ -1227,11 +1228,22 @@ static void hidp_session_run(struct hidp_session *session)
 		hidp_process_transmit(session, &session->ctrl_transmit,
 				      session->ctrl_sock);
 
-		schedule();
+		wait_woken(&wait, TASK_INTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT);
 	}
+	remove_wait_queue(&hidp_session_wq, &wait);
 
 	atomic_inc(&session->terminate);
-	set_current_state(TASK_RUNNING);
+
+	/* Ensure session->terminate is updated */
+	smp_mb__after_atomic();
+}
+
+static int hidp_session_wake_function(wait_queue_t *wait,
+				      unsigned int mode,
+				      int sync, void *key)
+{
+	wake_up_interruptible(&hidp_session_wq);
+	return false;
 }
 
 /*
@@ -1244,7 +1256,8 @@ static void hidp_session_run(struct hidp_session *session)
 static int hidp_session_thread(void *arg)
 {
 	struct hidp_session *session = arg;
-	wait_queue_t ctrl_wait, intr_wait;
+	DEFINE_WAIT_FUNC(ctrl_wait, hidp_session_wake_function);
+	DEFINE_WAIT_FUNC(intr_wait, hidp_session_wake_function);
 
 	BT_DBG("session %p", session);
 
@@ -1254,8 +1267,6 @@ static int hidp_session_thread(void *arg)
 	set_user_nice(current, -15);
 	hidp_set_timer(session);
 
-	init_waitqueue_entry(&ctrl_wait, current);
-	init_waitqueue_entry(&intr_wait, current);
 	add_wait_queue(sk_sleep(session->ctrl_sock->sk), &ctrl_wait);
 	add_wait_queue(sk_sleep(session->intr_sock->sk), &intr_wait);
 	/* This memory barrier is paired with wq_has_sleeper(). See
-- 
2.1.4

Re: [RESEND PATCH v4 1/3] Bluetooth: bnep: fix possible might sleep error in bnep_session

[Marcel Holtmann]

Hi Jeffy,

> It looks like bnep_session has same pattern as the issue reported in
> old rfcomm:
> 
> 	while (1) {
> 		set_current_state(TASK_INTERRUPTIBLE);
> 		if (condition)
> 			break;
> 		// may call might_sleep here
> 		schedule();
> 	}
> 	__set_current_state(TASK_RUNNING);
> 
> Which fixed at:
> 	dfb2fae Bluetooth: Fix nested sleeps
> 
> So let's fix it at the same way, also follow the suggestion of:
> https://lwn.net/Articles/628628/
> 
> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
> Reviewed-by: AL Yu-Chen Cho <acho@suse.com>
> ---
> 
> Changes in v4: None
> Changes in v2: None
> 
> net/bluetooth/bnep/core.c | 11 +++++------
> 1 file changed, 5 insertions(+), 6 deletions(-)

all 3 patches have been applied to bluetooth-next tree.

Regards

Marcel

Stable apply request [was: Bluetooth: bnep: fix possible might sleep error in bnep_session]

[Jiri Slaby]

On 06/27/2017, 07:32 PM, Marcel Holtmann wrote:
>> It looks like bnep_session has same pattern as the issue reported in
>> old rfcomm:
>>
>> 	while (1) {
>> 		set_current_state(TASK_INTERRUPTIBLE);
>> 		if (condition)
>> 			break;
>> 		// may call might_sleep here
>> 		schedule();
>> 	}
>> 	__set_current_state(TASK_RUNNING);
>>
>> Which fixed at:
>> 	dfb2fae Bluetooth: Fix nested sleeps
>>
>> So let's fix it at the same way, also follow the suggestion of:
>> https://lwn.net/Articles/628628/

...

> all 3 patches have been applied to bluetooth-next tree.

Hi,

given users are hitting it in at least 4.4 and 4.12, can we have all
three in all stables where this applies?

5da8e47d849d Bluetooth: hidp: fix possible might sleep error in
hidp_session_thread
f06d977309d0 Bluetooth: cmtp: fix possible might sleep error in cmtp_session
25717382c1dd Bluetooth: bnep: fix possible might sleep error in bnep_session

I am not sure: to stable directly or via net stable?

thanks,
-- 
js
suse labs

Re: Stable apply request

[David Miller]

From: Jiri Slaby <jslaby@suse.cz>
Date: Wed, 23 Aug 2017 09:29:44 +0200

> On 06/27/2017, 07:32 PM, Marcel Holtmann wrote:
>>> It looks like bnep_session has same pattern as the issue reported in
>>> old rfcomm:
>>>
>>> 	while (1) {
>>> 		set_current_state(TASK_INTERRUPTIBLE);
>>> 		if (condition)
>>> 			break;
>>> 		// may call might_sleep here
>>> 		schedule();
>>> 	}
>>> 	__set_current_state(TASK_RUNNING);
>>>
>>> Which fixed at:
>>> 	dfb2fae Bluetooth: Fix nested sleeps
>>>
>>> So let's fix it at the same way, also follow the suggestion of:
>>> https://lwn.net/Articles/628628/
> 
> ...
> 
>> all 3 patches have been applied to bluetooth-next tree.
> 
> Hi,
> 
> given users are hitting it in at least 4.4 and 4.12, can we have all
> three in all stables where this applies?
> 
> 5da8e47d849d Bluetooth: hidp: fix possible might sleep error in
> hidp_session_thread
> f06d977309d0 Bluetooth: cmtp: fix possible might sleep error in cmtp_session
> 25717382c1dd Bluetooth: bnep: fix possible might sleep error in bnep_session
> 
> I am not sure: to stable directly or via net stable?

I generally let the wireless family handle their own -stable submissions
and that includes bluetooth.

Re: Stable apply request [was: Bluetooth: bnep: fix possible might sleep error in bnep_session]

[Marcel Holtmann]

Hi Jiri,

>>> It looks like bnep_session has same pattern as the issue reported in
>>> old rfcomm:
>>> 
>>> 	while (1) {
>>> 		set_current_state(TASK_INTERRUPTIBLE);
>>> 		if (condition)
>>> 			break;
>>> 		// may call might_sleep here
>>> 		schedule();
>>> 	}
>>> 	__set_current_state(TASK_RUNNING);
>>> 
>>> Which fixed at:
>>> 	dfb2fae Bluetooth: Fix nested sleeps
>>> 
>>> So let's fix it at the same way, also follow the suggestion of:
>>> https://lwn.net/Articles/628628/
> 
> ...
> 
>> all 3 patches have been applied to bluetooth-next tree.
> 
> Hi,
> 
> given users are hitting it in at least 4.4 and 4.12, can we have all
> three in all stables where this applies?
> 
> 5da8e47d849d Bluetooth: hidp: fix possible might sleep error in
> hidp_session_thread
> f06d977309d0 Bluetooth: cmtp: fix possible might sleep error in cmtp_session
> 25717382c1dd Bluetooth: bnep: fix possible might sleep error in bnep_session
> 
> I am not sure: to stable directly or via net stable?

as Dave said, just email -stable directly and have Greg pick them up.

Regards

Marcel

Re: Stable apply request [was: Bluetooth: bnep: fix possible might sleep error in bnep_session]

[Greg KH]

On Wed, Aug 23, 2017 at 08:14:15PM +0200, Marcel Holtmann wrote:
> Hi Jiri,
> 
> >>> It looks like bnep_session has same pattern as the issue reported in
> >>> old rfcomm:
> >>> 
> >>> 	while (1) {
> >>> 		set_current_state(TASK_INTERRUPTIBLE);
> >>> 		if (condition)
> >>> 			break;
> >>> 		// may call might_sleep here
> >>> 		schedule();
> >>> 	}
> >>> 	__set_current_state(TASK_RUNNING);
> >>> 
> >>> Which fixed at:
> >>> 	dfb2fae Bluetooth: Fix nested sleeps
> >>> 
> >>> So let's fix it at the same way, also follow the suggestion of:
> >>> https://lwn.net/Articles/628628/
> > 
> > ...
> > 
> >> all 3 patches have been applied to bluetooth-next tree.
> > 
> > Hi,
> > 
> > given users are hitting it in at least 4.4 and 4.12, can we have all
> > three in all stables where this applies?
> > 
> > 5da8e47d849d Bluetooth: hidp: fix possible might sleep error in
> > hidp_session_thread
> > f06d977309d0 Bluetooth: cmtp: fix possible might sleep error in cmtp_session
> > 25717382c1dd Bluetooth: bnep: fix possible might sleep error in bnep_session
> > 
> > I am not sure: to stable directly or via net stable?
> 
> as Dave said, just email -stable directly and have Greg pick them up.

All now picked up :)