Hi Jiayang,
On Mon, Nov 25, 2024 at 12:51 PM Jiayang Mao <quic_jiaymao@xxxxxxxxxxx> wrote:
>
> Clear the remaining command in cmd_sync_work_list when BT is
> performing power off. In some cases, this list is not empty after
> power off. BT host will try to send more HCI commands.
> This can cause unexpected results.
What commands are in the queue?
> Signed-off-by: Jiayang Mao <quic_jiaymao@xxxxxxxxxxx>
> ---
> net/bluetooth/hci_sync.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
> index c86f4e42e..bc622d074 100644
> --- a/net/bluetooth/hci_sync.c
> +++ b/net/bluetooth/hci_sync.c
> @@ -5139,6 +5139,7 @@ int hci_dev_close_sync(struct hci_dev *hdev)
> {
> bool auto_off;
> int err = 0;
> + struct hci_cmd_sync_work_entry *entry, *tmp;
>
> bt_dev_dbg(hdev, "");
>
> @@ -5258,6 +5259,11 @@ int hci_dev_close_sync(struct hci_dev *hdev)
> clear_bit(HCI_RUNNING, &hdev->flags);
> hci_sock_dev_event(hdev, HCI_DEV_CLOSE);
>
> + mutex_lock(&hdev->cmd_sync_work_lock);
> + list_for_each_entry_safe(entry, tmp, &hdev->cmd_sync_work_list, list)
> + _hci_cmd_sync_cancel_entry(hdev, entry, -ECANCELED);
> + mutex_unlock(&hdev->cmd_sync_work_lock);
Seems equivalent to hci_cmd_sync_clear, that said we should have been
running with that lock already, also if there is a sequence like
close/open the close may cancel the subsequent open, so I don't think
we should be canceling every subsequent callback like this.
> /* After this point our queues are empty and no tasks are scheduled. */
> hdev->close(hdev);
>
> --
> 2.25.1
>
--
Luiz Augusto von Dentz
