linux-kernel - Re: [PATCH 0/4] PM / core: Direct handling of DPM_FLAG_SMART_SUSPEND and DPM_FLAG_LEAVE

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: <Pine.LNX.4.44L0.1801021053080.1633-100000@iolanthe.rowland.org>
Date:   Tue, 2 Jan 2018 10:57:51 -0500 (EST)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Ulf Hansson <ulf.hansson@...aro.org>
cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Kevin Hilman <khilman@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>
Subject: Re: [PATCH 0/4] PM / core: Direct handling of DPM_FLAG_SMART_SUSPEND
 and DPM_FLAG_LEAVE_SUSPENDED

On Tue, 2 Jan 2018, Ulf Hansson wrote:

> > While I acknowledge that Ulf doesn't appear to be convinced by my
> > arguments, I also see no technical reason why this cannot go in.
> 
> Correct, I am not convinced this is the right path as a general
> optimization, at least in it's current form. The main argument is
> about skipping invoking callbacks, as I have stated.
> 
> Moreover, I think we are lacking important input from some more
> experienced PM core code contributors, like Alan, Kevin etc. If any of
> those guys would give an ack, that would also make me more comfortable
> with this.
> 
> On the other hand, I realize that we can't wait forever for that to happen.

Sad to say, I have not been paying any significant attention to this 
patch series.  The major points I have gleaned are that these are all 
relatively small optimizations, and that by default the patches do not 
change existing behavior (they are opt-in).

So at first glance there's no pressing reason not to apply them.  But 
admittedly, this viewpoint ignores the larger picture.

Alan Stern