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]
Date:   Thu, 8 Jun 2017 09:48:17 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Rafael Wysocki <rjw@...ysocki.net>,
        Kevin Hilman <khilman@...nel.org>, Pavel Machek <pavel@....cz>,
        Len Brown <len.brown@...el.com>,
        linaro-kernel <linaro-kernel@...ts.linaro.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Nishanth Menon <nm@...com>, Rob Herring <robh+dt@...nel.org>,
        Lina Iyer <lina.iyer@...aro.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Sudeep Holla <sudeep.holla@....com>
Subject: Re: [PATCH V7 1/2] PM / Domains: Add support to select
 performance-state of domains

[...]

>> As you probably figured out from my above comments, the solution here
>> isn't really working.
>>
>> Adding these new APIs, more or less requires us to manage reference
>> counting on the genpd for the device.
>
> Hmm, I am not able to understand why would we need that with this series :(
>
>> I haven't thought about that in
>> great detail, just that we of course need to be careful if we want to
>> introduce something like that, to make sure all aspect of locking
>> becomes correct.
>>
>> Moreover adding reference counting touches the idea of adding APIs to
>> genpd, to allow users/drivers to control their genpd explicitly. This
>> is required to support > 1 pm_domain per device. I assume you have
>> been following that discussion for genpd on linux-pm as well. My point
>> is that, we should consider that while inventing *any* new APIs.
>
> Not very deeply but yeah I have seen that thread.
>
> So, I couldn't find way to get the locking thing fixed to avoid deadlocks but we
> can live with a constraint (if you guys think it is fine) to have this solved.
>
> Constraint: Update performance state API wouldn't support power domains that
> don't provide a set_performance_state() callback and have multiple parent power
> domains.

No thanks.

If we are going to do this, let's do it properly. To me some minor
constraints would be okay, but this is just too much.

>
> Why: In order to guarantee that we read and update the performance_state of
> subdomains and devices properly, we need to do that under the parent domain's
> lock. And if we have multiple parent power domains, then we would be required to
> get them locked at once before updating subdomain's state and that would be a
> nightmare.

It's not a nightmare, just a tricky thing to solve. :-)

[...]

Kind regards
Uffe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ