linux-kernel - Re: [PATCH v10 3/3] firmware: qcom_scm: Use TASK_IDLE 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <7580dd6f-564b-bb26-8322-5c4a132f6aa6@oss.qualcomm.com>
Date: Wed, 3 Dec 2025 16:27:25 +0530
From: Shivendra Pratap <shivendra.pratap@....qualcomm.com>
To: Mukesh Ojha <mukesh.ojha@....qualcomm.com>
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>,
        Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH v10 3/3] firmware: qcom_scm: Use TASK_IDLE state in
 wait_for_wq_completion()



On 12/3/2025 2:01 PM, Mukesh Ojha wrote:
> On Sun, Nov 30, 2025 at 08:11:04PM +0530, Shivendra Pratap wrote:
>> From: Unnathi Chalicheemala <unnathi.chalicheemala@....qualcomm.com>
>>
>> When the kernel issues an SMC (Secure Monitor Call) and the firmware
>> requests the kernel to wait, the waiting thread enters an
>> uninterruptible (D) state. In case of an extended wait request by the
>> firmware, any device suspend request, cannot proceed because of the
>> thread stuck in D state. This blocks the device suspend.
> 
> Not only that, it is stuck in D state after holding a mutex, which is
> more severe because none of the SMC calls can go through. However, this
> has been the case since the day the firmware started supporting waitq
> with a single context, which is somewhat acceptable as the firmware does
> not allow otherwise. Since, you are adding the multiple waitq context
> supported by firmware with your other patches,
> 
> Do you plan to support multiple waitq contexts i.e parallel SCM calls,
> in SCM driver as well ?

Yes. Parallel SCM can be enabled once this waitq enablement support is
in place.

thanks,
Shivendra