Skip to contentSkip to conversation

Bluetooth: Fix setting state back to TASK_RUNNING

PATCH In review Johan Hedberg 2 participants 2 messages Nov 19, 2014

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Bluetooth: Fix setting state back to TASK_RUNNING

From: Johan Hedberg <[email protected]>

In __hci_cmd_sync_ev() and __hci_req_sync() if the hci_req_run() call fails and we return from the functions we should ensure that the state doesn't remain in TASK_INTERRUPTIBLE that we just set it to. This patch fixes missing calls to set_current_state(TASK_RUNNING) in both places.

---
 net/bluetooth/hci_core.c | 2 ++
 1 file changed, 2 insertions(+)
net/bluetooth/hci_core.c +2 -0
index d786958a1dec..a67a4b8e4e1c 100644
@@ -1128,6 +1128,7 @@ struct sk_buff *__hci_cmd_sync_ev(struct hci_dev *hdev, u16 opcode, u32 plen,
 	err = hci_req_run(&req, hci_req_sync_complete);
 	if (err < 0) {
 		remove_wait_queue(&hdev->req_wait_q, &wait);
+		set_current_state(TASK_RUNNING);
 		return ERR_PTR(err);
 	}
 
@@ -1196,6 +1197,7 @@ static int __hci_req_sync(struct hci_dev *hdev,
 		hdev->req_status = 0;
 
 		remove_wait_queue(&hdev->req_wait_q, &wait);
+		set_current_state(TASK_RUNNING);
 
 		/* ENODATA means the HCI request command queue is empty.
 		 * This can happen when a request with conditionals doesn't
Signature · 1 line
2.1.0
maintainer
#1 lore raw

Hi Johan,

Quoted 11 lines

In __hci_cmd_sync_ev() and __hci_req_sync() if the hci_req_run() call fails and we return from the functions we should ensure that the state doesn't remain in TASK_INTERRUPTIBLE that we just set it to. This patch fixes missing calls to set_current_state(TASK_RUNNING) in both places.

---
net/bluetooth/hci_core.c | 2 ++

1 file changed, 2 insertions(+)

patch has been applied to bluetooth-next tree.

Regards

Marcel