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: <b597c805-e346-8c23-5014-cbb116e88075@gmail.com>
Date:   Fri, 3 Sep 2021 12:58:45 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Stephan Gerhold <stephan@...hold.net>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] PM: domains: Drop the performance state vote for a
 device at detach

03.09.2021 11:22, Ulf Hansson пишет:
> On Fri, 3 Sept 2021 at 08:01, Dmitry Osipenko <digetx@...il.com> wrote:
>>
>> 02.09.2021 13:16, Ulf Hansson пишет:
>>> When a device is detached from its genpd, genpd loses track of the device,
>>> including its performance state vote that may have been requested for it.
>>>
>>> Rather than relying on the consumer driver to drop the performance state
>>> vote for its device, let's do it internally in genpd when the device is
>>> getting detached. In this way, we makes sure that the aggregation of the
>>> votes in genpd becomes correct.
>>
>> This is a dangerous behaviour in a case where performance state
>> represents voltage. If hardware is kept active on detachment, say it's
>> always-on, then it may be a disaster to drop the voltage for the active
>> hardware.
>>
>> It's safe to drop performance state only if you assume that there is a
>> firmware behind kernel which has its own layer of performance management
>> and it will prevent the disaster by saying 'nope, I'm not doing this'.
>>
>> The performance state should be persistent for a device and it should be
>> controlled in a conjunction with runtime PM. If platform wants to drop
>> performance state to zero on detachment, then this behaviour should be
>> specific to that platform.
> 
> I understand your concern, but at this point, genpd can't help to fix this.
> 
> Genpd has no information about the device, unless it's attached to it.
> For now and for these always on HWs, we simply need to make sure the
> device stays attached, in one way or the other.

This indeed requires to redesign GENPD to make it more coupled with a
device, but this is not a real problem for any of the current API users
AFAIK. Ideally the state should be persistent to make API more universal.

Since for today we assume that device should be suspended at the time of
the detachment (if the default OPP state isn't used), it may be better
to add a noisy warning message if pstate!=0, keeping the state untouched
if it's not zero.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ