linux-kernel - Re: [PATCH 1/1] suspend: make sync() on suspend-to-RAM optional

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:	Sat, 01 Aug 2015 01:56:19 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Len Brown <lenb@...nel.org>, Oliver Neukum <oneukum@...e.com>
Cc:	Pavel Machek <pavel@....cz>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	"Brown, Len" <len.brown@...el.com>,
	Austin S Hemmelgarn <ahferroin7@...il.com>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] suspend: make sync() on suspend-to-RAM optional

On Friday, July 31, 2015 12:02:36 PM Len Brown wrote:
> On Wed, Jul 22, 2015 at 4:55 AM, Oliver Neukum <oneukum@...e.com> wrote:
> > On Wed, 2015-07-22 at 03:25 +0200, Rafael J. Wysocki wrote:
> >> And it is more pain for me to change the user space on each of them to
> >> write to the new sysfs file on every boot than to set a kernel Kconfig
> >> option once.
> >
> > So why at all? If you really need this in sysfs, why not write
> > something like "memfast" into /sys/power/state ?
> 
> We fought this battle, and lost.
> 
> When we came out with "freeze", which is faster than "mem",
> no user-space changed to take advantage of it.

I do think that Chrome is going to use "freeze", so maybe it's not a lost
battle after all?

The problem with "memfast" and similar things is we'd also need "freezefast"
and "standbyfast" then, for consistency if nothing else, which makes a little
sense to me.

BTW, it should be noted that the whole "sync in the kernel is better, because
it doesn't race with user space writing to disks" argument was completely
bogus and useless, because in fact the sync in the kernel is done before
freezing user space and which means that it is susceptible to the very same
race condition as the sync from user space.

So if your user space does the sync before suspending, the next one in the
kernel is completely useless.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/