linux-kernel - Re: [PATCH v8 3/3] firmware: qcom_scm: Check for waitq state in wait_for_wq

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <08cad799-f9c7-be69-b931-f4d6c218d1ea@oss.qualcomm.com>
Date: Mon, 17 Nov 2025 23:43:55 +0530
From: Shivendra Pratap <shivendra.pratap@....qualcomm.com>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Unnathi Chalicheemala <unnathi.chalicheemala@....qualcomm.com>
Subject: Re: [PATCH v8 3/3] firmware: qcom_scm: Check for waitq state in
 wait_for_wq_completion()

On 11/3/2025 9:21 PM, Bartosz Golaszewski wrote:
> On Sun, Nov 2, 2025 at 9:19 AM Shivendra Pratap
> <shivendra.pratap@....qualcomm.com> wrote:
>>
>> From: Unnathi Chalicheemala <unnathi.chalicheemala@....qualcomm.com>
>>
>> Modify wait_for_wq_completion() to check if task is in idle state using
>> wait_for_completion_state().
>>
> 
> This is not what's happening. wait_for_completion_state(comp,
> TASK_IDLE) puts the waiting task into TASK_IDLE state. It's not
> checking anything.

sure. Will update the commit message.

> 
>> This allows for detecting when waitq contexts are in idle state and
>> propagates it to __scm_smc_do(), which is beneficial when task is idle
>> and waiting for a kick to accept new requests.
>>
> 
> Could you elaborate on what benefit exactly this is giving us? It's
> not quite clear from this paragraph.

The TASK_IDLE state is introduced to handle scenarios where the kernel makes
a Secure Monitor Call and the firmware requests the kernel to wait.
During this wait, the thread typically enters an uninterruptible (D) state. 
If the firmware’s requested wait is long, and a device suspend request occurs
during that time, the suspend cannot proceed because the task is stuck in the
D state. To avoid blocking device suspend during these extended waits, the patch
adds support for TASK_IDLE state. This allows the thread to wait without the
device suspend.
Will update the commit message.

thanks,
Shivendra