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  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]
Date:   Sun, 2 Aug 2020 21:14:47 +0800 (GMT+08:00)
From:   王文虎 <wenhu.wang@...o.com>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     elder@...nel.org, davem@...emloft.net, kuba@...nel.org,
        kvalo@...eaurora.org, agross@...nel.org, ohad@...ery.com,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-remoteproc@...r.kernel.org, alsa-devel@...a-project.org,
        ath11k@...ts.infradead.org, netdev@...r.kernel.org,
        ath10k@...ts.infradead.org, linux-wireless@...r.kernel.org,
        srinivas.kandagatla@...aro.org, sibis@...eaurora.org
Subject: Re:Re: [PATCH] soc: qmi: allow user to set handle wq to hiprio


>> Currently the qmi_handle is initialized single threaded and strictly
>> ordered with the active set to 1. This is pretty simple and safe but
>> sometimes ineffency. So it is better to allow user to decide whether
>> a high priority workqueue should be used.
>
>Can you please describe a scenario where this is needed/desired and
>perhaps also comment on why this is not always desired?
>

Well, one scenario is that when the AP wants to check the status of the
subsystems and the whole QMI data path. It first sends out an indication
which asks the subsystems to report their status. After the subsystems send
responses to the AP, the responses then are queued on the workqueue of
the QMI handler. Actually the AP is configured to do the check in a specific
interval regularly. And it check the report counts within a specific delay after
it sends out the related indication. When the AP has been under a heavy
load for long, the reports are queue their without CPU resource to update
the report counts within the specific delay. As a result, the thread that checks
the report counts takes it misleadingly that the QMI data path or the subsystems
are crashed.

The patch can really resolve the problem mentioned abolve.

For narmal situations, it is enough to just use normal priority QMI workqueue.

>Regards,
>Bjorn
>
>> 
>> Signed-off-by: Wang Wenhu <wenhu.wang@...o.com>
>> ---
>>  drivers/net/ipa/ipa_qmi.c             | 4 ++--
>>  drivers/net/wireless/ath/ath10k/qmi.c | 2 +-
>>  drivers/net/wireless/ath/ath11k/qmi.c | 2 +-
>>  drivers/remoteproc/qcom_sysmon.c      | 2 +-
>>  drivers/slimbus/qcom-ngd-ctrl.c       | 4 ++--
>>  drivers/soc/qcom/pdr_interface.c      | 4 ++--
>>  drivers/soc/qcom/qmi_interface.c      | 9 +++++++--
>>  include/linux/soc/qcom/qmi.h          | 3 ++-
>>  samples/qmi/qmi_sample_client.c       | 4 ++--
>>  9 files changed, 20 insertions(+), 14 deletions(-)

Powered by blists - more mailing lists