linux-kernel - Re: [PATCH] PM: runtime: Return -EINPROGRESS from rpm_resume() in the RPM

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: <CAJZ5v0h5atuB5mdedfste5EiZKRFgz+7QGQUgWs+=sme4EKbig@mail.gmail.com>
Date:   Fri, 23 Sep 2022 17:52:58 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Linux PM <linux-pm@...r.kernel.org>,
        Douglas Anderson <dianders@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Alan Stern <stern@...land.harvard.edu>
Subject: Re: [PATCH] PM: runtime: Return -EINPROGRESS from rpm_resume() in the
 RPM_NOWAIT case

On Fri, Sep 23, 2022 at 3:26 PM Ulf Hansson <ulf.hansson@...aro.org> wrote:
>
> On Thu, 22 Sept 2022 at 20:04, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> >
> > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> >
> > The prospective callers of rpm_resume() passing RPM_NOWAIT to it may
> > be confused when it returns 0 without actually resuming the device
> > which may happen if the device is suspending at the given time and it
> > will only resume when the suspend in progress has completed.  To avoid
> > that confusion, return -EINPROGRESS from rpm_resume() in that case.
> >
> > Since none of the current callers passing RPM_NOWAIT to rpm_resume()
> > check its return value, this change has no functional impact.
>
> Sounds like there are additional improvements that can be made around
> this, right?

This allows RPM_NOWAIT to be used in places where the caller doesn't
want to wait, because it might deadlock or similar, but they still
need to know whether or not the device can be accessed safely.

Or do you mean something else?

> >
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>
> Looks good to me!
>
> Reviewed-by: Ulf Hansson <ulf.hansson@...aro.org>

Thanks!

> > ---
> >  drivers/base/power/runtime.c |    7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > Index: linux-pm/drivers/base/power/runtime.c
> > ===================================================================
> > --- linux-pm.orig/drivers/base/power/runtime.c
> > +++ linux-pm/drivers/base/power/runtime.c
> > @@ -792,10 +792,13 @@ static int rpm_resume(struct device *dev
> >                 DEFINE_WAIT(wait);
> >
> >                 if (rpmflags & (RPM_ASYNC | RPM_NOWAIT)) {
> > -                       if (dev->power.runtime_status == RPM_SUSPENDING)
> > +                       if (dev->power.runtime_status == RPM_SUSPENDING) {
> >                                 dev->power.deferred_resume = true;
> > -                       else
> > +                               if (rpmflags & RPM_NOWAIT)
> > +                                       retval = -EINPROGRESS;
> > +                       } else {
> >                                 retval = -EINPROGRESS;
> > +                       }
> >                         goto out;
> >                 }
> >
> >
> >
> >