linux-kernel - Re: [RFC][PATCH 0/2] PM / Sleep: Extended control of suspend/hibernate interfaces

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: <20111101081554.52ee5b38@notabene.brown>
Date:	Tue, 1 Nov 2011 08:15:54 +1100
From:	NeilBrown <neilb@...e.de>
To:	Ming Lei <tom.leiming@...il.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux PM list <linux-pm@...r.kernel.org>,
	mark gross <markgross@...gnar.org>,
	LKML <linux-kernel@...r.kernel.org>,
	John Stultz <john.stultz@...aro.org>,
	Alan Stern <stern@...land.harvard.edu>
Subject: Re: [RFC][PATCH 0/2] PM / Sleep: Extended control of
 suspend/hibernate interfaces

On Tue, 1 Nov 2011 03:55:50 +0800 Ming Lei <tom.leiming@...il.com> wrote:

> Hi,
> 
> On Fri, Oct 14, 2011 at 3:45 AM, Rafael J. Wysocki <rjw@...k.pl> wrote:
> 
> > Second, to address the backup problem, we need to allow user space
> > processes other than the suspend/hibernate process itself to prevent the
> > system from being put into sleep states.  A mechanism for that is introduced
> > by the second patch in the form of the /dev/sleepctl special device working
> > kind of like user space wakelocks on Android (although in a simplified
> > fashion).
> 
> I also have another similar example: write(fd, buffer, 100*4096).
> 
> Suppose only 80*4096 are copied into pages of the file, then someone
> run ' echo mem > /sys/power/state ' to trigger system sleep, so only
> partial writing is completed before system sleep and data inconsistence
> may be caused for the file on filesystem.
> 
> But I am not sure if it is possible to happen in reality.
> 
> thank,

I'm not sure if it is possible either, but even if it is it isn't a new
problem.  A suspend is expected to leave all sorts of external things in
inconsistent states. The contents of memory implicitly records all these
inconsistencies and allows them to be resolved in the normal course of things
after resume.
If you lose power to memory during suspend then you can certainly expect
filesystems to be corrupted in exactly the same sort of way that they can be
corrupted by a crash.  This has always been the case and I assume always will
(until we get main-memory that preserves state without power)

We want to block suspend during backups not to avoid corruption but simply to
allow the backups to complete promptly.

NeilBrown

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)