linux-kernel - Re: [PATCH] PM / QoS: Fix device resume latency PM QoS

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:   Wed, 25 Oct 2017 00:27:25 -0700
From:   Ramesh Thomas <ramesh.thomas@...el.com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Linux PM <linux-pm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Reinette Chatre <reinette.chatre@...el.com>,
        Alex Shi <alex.shi@...aro.org>,
        Ulf Hansson <ulf.hansson@...aro.org>
Subject: Re: [PATCH] PM / QoS: Fix device resume latency PM QoS

On 2017-10-24 at 13:23:23 +0200, Rafael J. Wysocki wrote:
> On Tue, Oct 24, 2017 at 10:49 AM, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> > On Tuesday, October 24, 2017 7:54:09 AM CEST Ramesh Thomas wrote:
> >> On 2017-10-20 at 13:27:34 +0200, Rafael J. Wysocki wrote:
> >> > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> >> >
> 
> [cut]
> 
> >> > @@ -63,10 +60,14 @@ static bool default_suspend_ok(struct de
> >> >
> >> >     spin_unlock_irqrestore(&dev->power.lock, flags);
> >> >
> >> > -   if (constraint_ns < 0)
> >> > +   if (constraint_ns == 0)
> >> >             return false;
> >> >
> >> > -   constraint_ns *= NSEC_PER_USEC;
> >> > +   if (constraint_ns == PM_QOS_RESUME_LATENCY_NO_CONSTRAINT)
> >> > +           constraint_ns = -1;
> >> > +   else
> >> > +           constraint_ns *= NSEC_PER_USEC;
> >> > +
> >> >     /*
> >> >      * We can walk the children without any additional locking, because
> >> >      * they all have been suspended at this point and their
> >> > @@ -76,14 +77,19 @@ static bool default_suspend_ok(struct de
> >> >             device_for_each_child(dev, &constraint_ns,
> >> >                                   dev_update_qos_constraint);
> >> >
> >> > -   if (constraint_ns > 0) {
> >> > -           constraint_ns -= td->suspend_latency_ns +
> >> > -                           td->resume_latency_ns;
> >> > -           if (constraint_ns == 0)
> >> > -                   return false;
> >> > +   if (constraint_ns < 0) {
> >> > +           /* The children have no constraints. */
> >> > +           td->effective_constraint_ns = PM_QOS_RESUME_LATENCY_NO_CONSTRAINT;
> >> > +           td->cached_suspend_ok = true;
> >> > +   } else {
> >> > +           constraint_ns -= td->suspend_latency_ns + td->resume_latency_ns;
> >> > +           if (constraint_ns > 0) {
> >> > +                   td->effective_constraint_ns = constraint_ns;
> >> > +                   td->cached_suspend_ok = true;
> >> > +           } else {
> >> > +                   td->effective_constraint_ns = 0;
> >>
> >> Previously effective_constraint_ns was left as -1 if constraint_ns becomes 0
> >> Not sure if this change is intentional.
> >
> > Yes, it is.
> >
> >> I think at dev_update_qos_constraint, this can cause to skip call to
> >> dev_pm_qos_read_value.
> >
> > I need to double check that.
> 
> If constraint_ns becomes 0 (or less) here, power cannot be removed
> from the device, because it would add an unacceptable latency.
> 
> Thus effective_constraint_ns has to be 0 for it to indicate that
> situation.  If it was left at -1, it would mean "no requirement", but
> that wouldn't be correct.
> 

A negative value in effective_constraint_ns is used as trigger to read new
resume latency constraints.

Here the parent of this device will not use this value when this functions
returns false for this device as that means it is not going to suspend. Only
other function that will use it is __default_power_down_ok. That function also
needs to consider a changed new resume latency constraints which it won't if
this does not have a negative value or if __default_power_down_ok does not
itself initialize it to -1 before starting its calculation like
default_suspend_ok does.

Thanks,
Ramesh