linux-kernel - Re: [PATCH v1] Bluetooth: hci_qca: Fix SSR unable to wake up bug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0c54ccc4-0526-4d7a-9ce3-42dde5539c7b@molgen.mpg.de>
Date: Tue, 4 Nov 2025 12:43:20 +0100
From: Paul Menzel <pmenzel@...gen.mpg.de>
To: Shuai Zhang <quic_shuaz@...cinc.com>
Cc: Bartosz Golaszewski <brgl@...ev.pl>, Marcel Holtmann
 <marcel@...tmann.org>, Luiz Augusto von Dentz <luiz.dentz@...il.com>,
 linux-arm-msm@...r.kernel.org, linux-bluetooth@...r.kernel.org,
 linux-kernel@...r.kernel.org, stable@...r.kernel.org,
 quic_chejiang@...cinc.com, quic_jiaymao@...cinc.com, quic_chezhou@...cinc.com
Subject: Re: [PATCH v1] Bluetooth: hci_qca: Fix SSR unable to wake up bug

Dear Shuai,


Thank you for your patch.

Am 04.11.25 um 12:26 schrieb Shuai Zhang:
> During SSR data collection period, the processing of hw_error events
> must wait until SSR data Collected or the timeout before it can proceed.

Collected → collected

> The wake_up_bit function has been added to address the issue

has been added → is added

> where hw_error events could only be processed after the timeout.

The problem is not totally clear to me. What is the current situation? 
Maybe start the commit message with that?

> The timeout unit has been changed from jiffies to milliseconds (ms).

Please give the numbers, and also document effect of this change. Is the 
timeout the same, or different?

Also, why not make that a separate commit?

Please document a test case.

> Cc: stable@...r.kernel.org
> Signed-off-by: Shuai Zhang <quic_shuaz@...cinc.com>
> ---
>   drivers/bluetooth/hci_qca.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index 888176b0f..a2e3c97a8 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -1105,6 +1105,7 @@ static void qca_controller_memdump(struct work_struct *work)
>   				cancel_delayed_work(&qca->ctrl_memdump_timeout);
>   				clear_bit(QCA_MEMDUMP_COLLECTION, &qca->flags);
>   				clear_bit(QCA_IBS_DISABLED, &qca->flags);
> +				wake_up_bit(&qca->flags, QCA_MEMDUMP_COLLECTION);
>   				mutex_unlock(&qca->hci_memdump_lock);
>   				return;
>   			}
> @@ -1182,6 +1183,7 @@ static void qca_controller_memdump(struct work_struct *work)
>   			qca->qca_memdump = NULL;
>   			qca->memdump_state = QCA_MEMDUMP_COLLECTED;
>   			clear_bit(QCA_MEMDUMP_COLLECTION, &qca->flags);
> +			wake_up_bit(&qca->flags, QCA_MEMDUMP_COLLECTION);

`include/linux/wait_bit.h` also contains `clear_and_wake_up_bit()`.

>   		}
>   
>   		mutex_unlock(&qca->hci_memdump_lock);
> @@ -1602,7 +1604,7 @@ static void qca_wait_for_dump_collection(struct hci_dev *hdev)
>   	struct qca_data *qca = hu->priv;
>   
>   	wait_on_bit_timeout(&qca->flags, QCA_MEMDUMP_COLLECTION,
> -			    TASK_UNINTERRUPTIBLE, MEMDUMP_TIMEOUT_MS);
> +			    TASK_UNINTERRUPTIBLE, msecs_to_jiffies(MEMDUMP_TIMEOUT_MS));
>   
>   	clear_bit(QCA_MEMDUMP_COLLECTION, &qca->flags);
>   }


Kind regards,

Paul