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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ