linux-kernel - Re: [PATCH]: In kernel hibernation, suspend to both

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: <1336955981.2190.13.camel@shrek.rexursive.com>
Date:	Mon, 14 May 2012 10:39:41 +1000
From:	Bojan Smojver <bojan@...ursive.com>
To:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux PM list <linux-pm@...r.kernel.org>,
	linux-kernel@...r.kernel.org, bp@...en8.de
Subject: Re: [PATCH]: In kernel hibernation, suspend to both

On Mon, 2012-05-14 at 05:19 +0530, Srivatsa S. Bhat wrote:
> But does it carry out suspend-to-ram in full, or does it skip the
> PM_SUSPEND_PREPARE notifications?

As far as I can see, it simply does an ioctl that suspends to RAM
immediately, without any prior notifications.

> See my concerns about the preparation stage for suspend, in my other
> mail as well. I would have been less worried if we did things in full:
> 1. prepare for hibernation
> 2. create image
> 3. prepare for suspend
> 4. do suspend
> 5. do resume
> 6. unwind from hibernation code (like a failed hibernation).
> 
> Still no guarantees, but somewhat better.
> (consider what will happen if some code expects completion of an
> operation,
> successful or otherwise, before starting another.. and hence is
> unprepared
> for something like:
> hibernation prepare -> suspend prepare -> post suspend -> post
> hibernation)

What I'm trying to say is that from the point of view of the rest of the
code, suspend to RAM never happened. Only a failed hibernation happened.

At the point where we suspend to RAM, only the devices that are required
for image writing are actually active. The rest is frozen, including all
the processes, if I'm understanding things correctly.

If these devices can survive a failed image writing and are then be
subjected to unwinding by hibernation code, how would a suspend to RAM
right in the middle change any of this? Maybe it does - don't really
know...

> If we don't rework this thing carefully via a special notification for
> save-image-and-suspend like what Rafael suggested, and instead try to
> go
> with existing stuff as it is, I would definitely suggest putting this
> feature
> under something like CONFIG_EXPERIMENTAL ;-) 

Yeah, possibly.

-- 
Bojan

--
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/