linux-kernel - Re: [PATCH] PM / suspend: Count suspend-to-idle loop as sleep time

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: <CAJZ5v0iw99hWVY6P+uxOwZR4CkJJAbSytKuMr5Qk2-TYvzftCQ@mail.gmail.com>
Date:   Mon, 17 Sep 2018 10:08:05 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        mika.penttila@...tfour.com,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Linux PM <linux-pm@...r.kernel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>
Subject: Re: [PATCH] PM / suspend: Count suspend-to-idle loop as sleep time

On Fri, Sep 14, 2018 at 2:41 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>
> On Fri, 14 Sep 2018, Rafael J. Wysocki wrote:
> > On Fri, Sep 14, 2018 at 11:53 AM Mika Penttilä
>
> > > >> But doesn't injecting sleep time here make monotonic clock too large
> > > >> by the amount of sleeptime?  tick_freeze() / tick_unfreeze() already
> > > >> injects the sleeptime (otherwise delta would be 0).  > > >
> > > >
> > > > No, it doesn't.
> > > >
> > > > The delta here is the extra time taken by the loop which hasn't been counted
> > > > as sleep time yet.
> > >
>
> > > I said incorrectly monotonic clock, but
> > > timekeeping_inject_sleeptime64() forwards the wall time, by the amount
> > > of delta.  Why wouldn't some other cpu update xtime when one cpu is in
> > > the loop? And if all cpus enter s2idle, tick_unfreeze() injects
> > > sleeptime. My point is that this extra injection makes wall time wrong,
> > > no?
> >
> > OK, you're right.  I got that the other way around.
> >
> > So, the patch is withdrawn.

[Sorry for the delay, personal life intervened.]

> I just tried to wrap my brain around that whole thing and utterly
> failed, so I can't give any recommendations right now.

Thanks for looking into this!

> Rafael, could you please enable some lightweight instrumentation which lets
> me see the longer sequence of events which are leading to this or tell me
> what I need to do to reproduce that myself?

I will, when I find out more.  The reported issues may just go away
after fixing some other bugs.

Cheers,
Rafael