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-next>] [day] [month] [year] [list]
Date:   Thu, 1 Sep 2016 17:09:36 +0800
From:   qiaozhou <qiaozhou@...micro.com>
To:     <tj@...nel.org>, <linux-pm@...r.kernel.org>,
        Wang Wilbur <wilburwang@...micro.com>,
        Wu Gang <gangwu@...micro.com>, <linux-kernel@...r.kernel.org>
Subject: [Question] about patch: don't use [delayed_]work_pending()

Hi Tejun,

I have a question related with below patch, and need your suggestion.

In our system, we do cpu clock init in of_clk_init path, and use pm qos 
to maintain cpu/cci clock. Firstly we init a CCI_CLK_QOS and set a 
default value, then update CCI_CLK_QOS to limit CCI min frequency 
according to current cpu frequency. Before calling 
pm_qos_update_request, irq is disabled, but after the calling, irq is 
enabled in cancel_delayed_work_sync, which causes some inconvenience 
before Before this patch is applied, it checks pending work and won't do 
cancel_delayed_work_sync in this boot up phase.

The simple calling sequence is like this:

start_kernel -> of_clk_init -> cpu_clk_init -> pm_qos_add_request(xx, 
default_value),

then pm_qos_update_request.

I don't know whether it's meaningful to still check pending work here, 
or it's not suggested to use pm_qos_update_request in this early boot up 
phase. Could you help to share some opinions? (I can fix this issue by 
adding the current qos value directly instead of default value, though.)

Thanks a lot.

commit ed1ac6e91a3ff7c561008ba57747cd6cbc49385e
Author: Tejun Heo <tj@...nel.org>
Date:   Fri Jan 11 13:37:33 2013 +0100

     PM: don't use [delayed_]work_pending()

     There's no need to test whether a (delayed) work item is pending
     before queueing, flushing or cancelling it, so remove work_pending()
     tests used in those cases.

     Signed-off-by: Tejun Heo <tj@...nel.org>
     Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>

...

@@ -359,8 +359,7 @@ void pm_qos_update_request(struct pm_qos_request *req,
                 return;
         }

-       if (delayed_work_pending(&req->work))
-               cancel_delayed_work_sync(&req->work);
+       cancel_delayed_work_sync(&req->work);
...

Best Regards

Qiao

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ