* [RESEND PATCH v4 1/3] Bluetooth: bnep: fix possible might sleep error in bnep_session
@ 2017-06-27 9:34 Jeffy Chen
2017-06-27 9:34 ` [RESEND PATCH v4 2/3] Bluetooth: cmtp: fix possible might sleep error in cmtp_session Jeffy Chen
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Jeffy Chen @ 2017-06-27 9:34 UTC (permalink / raw)
To: linux-kernel, linux-bluetooth
Cc: rvaswani, briannorris, dmitry.torokhov, dianders, acho,
Jeffy Chen, Johan Hedberg, netdev, David S. Miller,
Marcel Holtmann, Gustavo Padovan
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
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [RESEND PATCH v4 2/3] Bluetooth: cmtp: fix possible might sleep error in cmtp_session
2017-06-27 9:34 [RESEND PATCH v4 1/3] Bluetooth: bnep: fix possible might sleep error in bnep_session Jeffy Chen
@ 2017-06-27 9:34 ` Jeffy Chen
2017-06-27 9:34 ` Jeffy Chen
2017-06-27 17:32 ` [RESEND PATCH v4 1/3] Bluetooth: bnep: fix possible might sleep error in bnep_session Marcel Holtmann
2 siblings, 0 replies; 9+ messages in thread
From: Jeffy Chen @ 2017-06-27 9:34 UTC (permalink / raw)
To: linux-kernel, linux-bluetooth
Cc: rvaswani, briannorris, dmitry.torokhov, dianders, acho,
Jeffy Chen, Johan Hedberg, netdev, David S. Miller,
Marcel Holtmann, Gustavo Padovan
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
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [RESEND PATCH v4 3/3] Bluetooth: hidp: fix possible might sleep error in hidp_session_thread
@ 2017-06-27 9:34 ` Jeffy Chen
0 siblings, 0 replies; 9+ messages in thread
From: Jeffy Chen @ 2017-06-27 9:34 UTC (permalink / raw)
To: linux-kernel, linux-bluetooth
Cc: rvaswani, briannorris, dmitry.torokhov, dianders, acho,
Jeffy Chen, Johan Hedberg, netdev, David S. Miller,
Marcel Holtmann, Gustavo Padovan
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@rock-chips.com>
Tested-by: AL Yu-Chen Cho <acho@suse.com>
Tested-by: Rohit Vaswani <rvaswani@nvidia.com>
---
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
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [RESEND PATCH v4 3/3] Bluetooth: hidp: fix possible might sleep error in hidp_session_thread
@ 2017-06-27 9:34 ` Jeffy Chen
0 siblings, 0 replies; 9+ messages in thread
From: Jeffy Chen @ 2017-06-27 9:34 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
Cc: rvaswani-DDmLM1+adcrQT0dZR+AlfA,
briannorris-F7+t8E8rja9g9hUCZPvPmw,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
dianders-F7+t8E8rja9g9hUCZPvPmw, acho-IBi9RG/b67k, Jeffy Chen,
Johan Hedberg, netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
Marcel Holtmann, Gustavo Padovan
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
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [RESEND PATCH v4 1/3] Bluetooth: bnep: fix possible might sleep error in bnep_session
2017-06-27 9:34 [RESEND PATCH v4 1/3] Bluetooth: bnep: fix possible might sleep error in bnep_session Jeffy Chen
2017-06-27 9:34 ` [RESEND PATCH v4 2/3] Bluetooth: cmtp: fix possible might sleep error in cmtp_session Jeffy Chen
2017-06-27 9:34 ` Jeffy Chen
@ 2017-06-27 17:32 ` Marcel Holtmann
2017-08-23 7:29 ` Stable apply request [was: Bluetooth: bnep: fix possible might sleep error in bnep_session] Jiri Slaby
2 siblings, 1 reply; 9+ messages in thread
From: Marcel Holtmann @ 2017-06-27 17:32 UTC (permalink / raw)
To: Jeffy Chen
Cc: LKML, open list:BLUETOOTH DRIVERS, rvaswani, Brian Norris,
dmitry.torokhov, Douglas Anderson, acho, Johan Hedberg,
Network Development, David S. Miller, Gustavo F. Padovan
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Stable apply request [was: Bluetooth: bnep: fix possible might sleep error in bnep_session]
2017-06-27 17:32 ` [RESEND PATCH v4 1/3] Bluetooth: bnep: fix possible might sleep error in bnep_session Marcel Holtmann
@ 2017-08-23 7:29 ` Jiri Slaby
2017-08-23 18:07 ` Stable apply request David Miller
2017-08-23 18:14 ` Stable apply request [was: Bluetooth: bnep: fix possible might sleep error in bnep_session] Marcel Holtmann
0 siblings, 2 replies; 9+ messages in thread
From: Jiri Slaby @ 2017-08-23 7:29 UTC (permalink / raw)
To: Marcel Holtmann, Jeffy Chen, stable
Cc: LKML, open list:BLUETOOTH DRIVERS, rvaswani, Brian Norris,
dmitry.torokhov, Douglas Anderson, acho, Johan Hedberg,
Network Development, David S. Miller, Gustavo F. Padovan
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Stable apply request
2017-08-23 7:29 ` Stable apply request [was: Bluetooth: bnep: fix possible might sleep error in bnep_session] Jiri Slaby
@ 2017-08-23 18:07 ` David Miller
2017-08-23 18:14 ` Stable apply request [was: Bluetooth: bnep: fix possible might sleep error in bnep_session] Marcel Holtmann
1 sibling, 0 replies; 9+ messages in thread
From: David Miller @ 2017-08-23 18:07 UTC (permalink / raw)
To: jslaby
Cc: marcel, jeffy.chen, stable, linux-kernel, linux-bluetooth,
rvaswani, briannorris, dmitry.torokhov, dianders, acho,
johan.hedberg, netdev, gustavo
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Stable apply request [was: Bluetooth: bnep: fix possible might sleep error in bnep_session]
2017-08-23 7:29 ` Stable apply request [was: Bluetooth: bnep: fix possible might sleep error in bnep_session] Jiri Slaby
2017-08-23 18:07 ` Stable apply request David Miller
@ 2017-08-23 18:14 ` Marcel Holtmann
2017-08-27 13:10 ` Greg KH
1 sibling, 1 reply; 9+ messages in thread
From: Marcel Holtmann @ 2017-08-23 18:14 UTC (permalink / raw)
To: Jiri Slaby
Cc: Jeffy Chen, stable, LKML, open list:BLUETOOTH DRIVERS, rvaswani,
Brian Norris, dmitry.torokhov, Douglas Anderson, acho,
Johan Hedberg, Network Development, David S. Miller,
Gustavo F. Padovan
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Stable apply request [was: Bluetooth: bnep: fix possible might sleep error in bnep_session]
2017-08-23 18:14 ` Stable apply request [was: Bluetooth: bnep: fix possible might sleep error in bnep_session] Marcel Holtmann
@ 2017-08-27 13:10 ` Greg KH
0 siblings, 0 replies; 9+ messages in thread
From: Greg KH @ 2017-08-27 13:10 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Jiri Slaby, Jeffy Chen, stable, LKML,
open list:BLUETOOTH DRIVERS, rvaswani, Brian Norris,
dmitry.torokhov, Douglas Anderson, acho, Johan Hedberg,
Network Development, David S. Miller, Gustavo F. Padovan
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 :)
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-08-27 13:10 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-27 9:34 [RESEND PATCH v4 1/3] Bluetooth: bnep: fix possible might sleep error in bnep_session Jeffy Chen
2017-06-27 9:34 ` [RESEND PATCH v4 2/3] Bluetooth: cmtp: fix possible might sleep error in cmtp_session Jeffy Chen
2017-06-27 9:34 ` [RESEND PATCH v4 3/3] Bluetooth: hidp: fix possible might sleep error in hidp_session_thread Jeffy Chen
2017-06-27 9:34 ` Jeffy Chen
2017-06-27 17:32 ` [RESEND PATCH v4 1/3] Bluetooth: bnep: fix possible might sleep error in bnep_session Marcel Holtmann
2017-08-23 7:29 ` Stable apply request [was: Bluetooth: bnep: fix possible might sleep error in bnep_session] Jiri Slaby
2017-08-23 18:07 ` Stable apply request David Miller
2017-08-23 18:14 ` Stable apply request [was: Bluetooth: bnep: fix possible might sleep error in bnep_session] Marcel Holtmann
2017-08-27 13:10 ` Greg KH
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.