Skip to content

Commit d73e172

Browse files
l1kholtmann
authored andcommitted
Bluetooth: hci_serdev: Init hci_uart proto_lock to avoid oops
John Stultz reports a boot time crash with the HiKey board (which uses hci_serdev) occurring in hci_uart_tx_wakeup(). That function is contained in hci_ldisc.c, but also called from the newer hci_serdev.c. It acquires the proto_lock in struct hci_uart and it turns out that we forgot to init the lock in the serdev code path, thus causing the crash. John bisected the crash to commit 67d2f87 ("Bluetooth: hci_ldisc: Allow sleeping while proto locks are held"), but the issue was present before and the commit merely exposed it. (Perhaps by luck, the crash did not occur with rwlocks.) Init the proto_lock in the serdev code path to avoid the oops. Stack trace for posterity: Unable to handle kernel read from unreadable memory at 406f127000 [000000406f127000] user address but active_mm is swapper Internal error: Oops: 96000005 [#1] PREEMPT SMP Hardware name: HiKey Development Board (DT) Call trace: hci_uart_tx_wakeup+0x38/0x148 hci_uart_send_frame+0x28/0x38 hci_send_frame+0x64/0xc0 hci_cmd_work+0x98/0x110 process_one_work+0x134/0x330 worker_thread+0x130/0x468 kthread+0xf8/0x128 ret_from_fork+0x10/0x18 Link: https://lkml.org/lkml/2017/11/15/908 Reported-and-tested-by: John Stultz <[email protected]> Cc: Ronald Tschalär <[email protected]> Cc: Rob Herring <[email protected]> Cc: Sumit Semwal <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
1 parent e7232d1 commit d73e172

File tree

1 file changed

+1
-0
lines changed

1 file changed

+1
-0
lines changed

drivers/bluetooth/hci_serdev.c

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -303,6 +303,7 @@ int hci_uart_register_device(struct hci_uart *hu,
303303
hci_set_drvdata(hdev, hu);
304304

305305
INIT_WORK(&hu->write_work, hci_uart_write_work);
306+
percpu_init_rwsem(&hu->proto_lock);
306307

307308
/* Only when vendor specific setup callback is provided, consider
308309
* the manufacturer information valid. This avoids filling in the

0 commit comments

Comments
 (0)